The speaker presented a modified proposal based on a presentation made to the SIG at APNIC 14. The speaker summarised the problems lame DNS can cause, such as increased DNS traffic. The speaker noted that lame DNS does not just affect the holder of the lame DNS delegations, but that it also affects third parties on the Internet attempting to resolve DNS queries.

It was proposed that the process for identifying potential lameness be modified following lessons learned at the test cleanup. It was noted that delegations must be consistently lame for a fifteen day period. Any delegations that are not lame at any point during the fifteen days would not be included in the cleanup.

It was also proposed that lame DNS delegations be disabled by a marker in the domain object. It was noted that if all nameservers listed in a reverse DNS delegation are found to be invalid, all subdomains will also be withdrawn.

It was proposed that the cleanup begin three months after the proposal was approved by the APNIC community.

Questions and discussion

Concern was expressed that there was a shame and blame list published for the fifteen day period, but not for the forty-five day contact period. It was suggested that it would be preferable that the forty-five day period have a list published rather than the fifteen day period. The speaker was happy to make that change.

It was noted that at APNIC 15 there was concern expressed that the process should be in line with the ARIN meeting decision. The new proposal aligns with ARIN policy on lame delegation.

It was suggested that it was not good to allow only one nameserver to be provided for a reverse DNS delegation. The speaker noted that this was a problem, but not related to the proposal being given. The speaker noted that there was currently activity underway to formalise the quality of DNS, including the definition of lameness, and APNIC would adopt those recommendations.

It was asked if it would be possible to flag objects in the database with only one nameserver as poorly formed delegations. The speaker noted that this was possible and could be discussed further.

There was a question from JPNIC what would happen if one nameserver was lame, but the other was not. It was noted that at the moment, the project was only related to objects directly managed by APNIC and not objects managed by others. The speaker suggested that from discussions with others, it did not seem appropriate to say that if one nameserver is broken, but another is working, the complete domain should be disabled.

This presentation referred to an Internet Draft on the 6to4 delegation process and examined the implications for the registration of delegations by the RIRs.

The speaker referred to the 6to4 specifications detailed in RFC 3056. The speaker explained that while forward DNS worked well for 6to4, reverse DNS was more complicated. The speaker noted that holders of IPv4 space should be able to request reverse delegation for the corresponding section of 2.0.0.2.ip6.arpa. However, the RIRs delegate IPv4 by in-addr.arpa. So RIRs should be able to delegate the corresponding 2.0.0.2.ip6.arpa registration at the same time. However, the speaker noted, not all upstream providers may provide IPv6 connectivity, leading to problems for 6to4 delegations. The solution to the problem would mean going up the delegation chain to find the most specific match. However, in many situations, this most specific match would be the RIRs. The speaker suggested that this could have policy and technology implications for the RIRs.

The speaker noted that use of 6to4 was not that common. Requests to RIRs for reverse delegations in this space would probably in the range of one hundred. In the AP region, the speaker suggested that requests would probably be even fewer due to the ease of access to native IPv6.

Questions and discussion

There was a comment that in 2002, there were 127 delegations in the old ip6.int space. Therefore, the speaker's forecast for possible 6to4 reverse DNS delegations was probably fairly accurate.

There was a question about the status of the Internet Draft the speaker was referring to in the presentation. The speaker noted that the Internet Draft was in its last call from July 14 and should be ending very soon.

This presentation examined how to populate delegations of address space from the 6to4 address range. The speaker noted that there had been a number of options explored to date, such as supporting a "guessing server" to fudge the delegation tree. However, such suggestions would require some dramatic compromises.

The speaker referred to the issues raised by the 6to4 delegation scheme discussed in the previous presentation by Randy Bush. He noted that there was a certain amount of unreliability in it due to the need to hop up to the most specific parent delegation available.

The speaker suggested that the process for registering delegations could be automated and include an automatic lameness check. An automated service would solve the hop-over problem mentioned by the previous speaker, which occurs when a network in the delegation tree does not support IPv6. One problem, however, would be that clients inside a 6to4 network could update the servers without the knowledge of the network administrator.

It was noted that if IPv4 address space was hijacked, there are so many other more important operational issues that could be disturbed, and that registering a 6to4 delegation would be very small in comparison. The speaker acknowledged that his solution to the 6to4 reverse DNS delegation problem was only a hack, and suggested that networks may find it easier to move to native IPv6.

Questions and discussion

It was noted that for people registering a prefix length, the 6to4 implementations of hardware and software in 1998 would be very different to the 6to4 implementation in 2002.

There was a suggestion that if whois was fixed, the problem would be lessened. It was noted, however, that one of the stated goals of the proposal was to keep the overheads low, and that the suggestion to fix whois would make overheads higher.

Attendees running 6to4 were asked to raise their hands. Two hands were raised.

It was noted that in the ARIN region, the cost of implementing this proposal would be greater than simply doing the registrations by email. The speaker acknowledged that this was a good point. He noted that from the discussion in the SIG, it seemed that doing it manually might be a better solution.

It was suggested that the email contact could be useful in the delegation process, as well as the date flag.