[dns-wg] Followup to IANA TLD delegation problem

Jim,

Thanks again for the opportunity to discuss these issues. I hope that the
group finds these answers satisfactory. We are of course happy to discuss
this in further detail if desired.

[1] What was the nature of the technical problem that prevented
multiple names in for an IP address and how was it resolved?

In November of 2004 AFNIC asked to have several hostnames added to the root
zone that resolved to the same IPv4 addresses as hostnames that already
existed. When VeriSign edited the root zone to include these new names, an
unexpected result occurred. In some of the TLDs that had the pre-existing
hostnames for these servers, the new hostnames appeared in the delegations
inappropriately. This problem was identified within several hours of the
zone going live by VeriSign staff, as well as at least one member of the
ccTLD community. The VeriSign and IANA staffs communicated immediately about
this issue, and the specific problem related to this request was fixed
manually by VeriSign in the next zone revision after it was identified.

Because in any pair of hostnames affected by this result the IPv4 address
was the same, the operational impact of this problem was minimal, if it was
identifiable at all.


[2] Why was there no announcement that this problem existed?

The specific problem applied only to new instances of duplicate names, it
did not affect existing duplicate names for which no change was in process.
The total number of these duplicate hostnames is very small relative to the
rest of the zone (less than 3%), and requests to modify domains which have
these hostnames in their delegations are rare. There were no instances of
such a request from November of 2004 through March of 2005, when AFNIC
submitted the request for the RE ccTLD.

Because the issue affected only a small number of TLDs and name server
operators, IANA staff chose to address the issue with those individuals
directly. Often TLD managers appreciate such specific cases being dealt with
on a personal level.


[3] Are safeguards now in place to prevent this sort of problem recurring?

Yes. VeriSign has informed us that the general problem which produced the
original unexpected result has now been corrected. Additionally, IANA staff
have enhanced efforts to monitor the "live" root zone from several different
servers, and use that data to proactively monitor the results of change
requests.


[4] What procedures does IANA (or ICANN?) have to make sure that changes
to the TLD delegation process or problems with that process are properly
communicated to its stakeholders?

The procedure that IANA uses to communicate changes in the TLD delegation
process follows the typical ICANN formula of involving key stakeholders at
early stages, opening proposals up for public comment, incorporating
appropriate comments into the final version, and posting the procedure for
its stakeholders. A relevant example of this process is the "Delegation Data
Procedure," which is posted at
http://www.iana.org/procedures/delegation-data.html.

Specific problems in the root management process are evaluated on a case by
case basis. When necessary, there is a mailing list composed of the contact
addresses for each of the TLD managers that can be utilized for any issue of
wide interest to the TLD manager community. As noted above, cases which
affect one, or a few TLDs are often dealt with on a one-to-one basis, with
the appreciation of the relevant TLD manager(s).


[5] Were those procedures followed for this incident? If not, why not?

The procedure for communicating changes to the TLD delegation process was
not followed in this specific case because there was no formal change of
process.

The specific problem which produced the delay in processing AFNIC's request
for RE was always understood to be temporary. As discussed above, rather
than widely disseminate the information about this issue to the TLD manager
community, IANA staff chose to communicate directly with those affected by
the issue.


ICANN's goal, as always, is to cooperate with the TLD managers in
implementing the changes they feel are appropriate for their TLDs, while
also maintaining the stability of the DNS. We regret if our cautious
handling of this particular request, or the timing of our responses to the
group's reasonable questions, has caused any undue confusion in the DNS
community about ICANN's dedication to that goal. We welcome comment and
discussion on these topics.

I am enclosing below some information about the current (at this writing,
2005061000) root zone that may be relevant to this discussion. The first
part is the complete list of IPv4 addresses that have multiple hostnames
associated. There are no IPv6 addresses with multiple hostnames. The second
part is a compilation of statistics about the current zone.

Regards,

Doug


128.112.129.15:	dns.princeton.edu c.ext.nic.fr
192.134.0.49:	c.nic.fr ns3.nic.fr
192.36.144.116:	slave.sth.netnod.se slave1.sth.netnod.se
192.93.0.1:	a.nic.fr ns1.nic.fr
192.93.0.4:	b.nic.fr ns2.nic.fr
193.176.144.6:	e.ext.nic.fr ns3.domain-registry.nl
193.51.208.13:	dns.inria.fr a.ext.nic.fr
204.152.184.64:	ns-ext.vix.com ns-ext.isc.org
204.74.112.1:	tld1.basicfusion.net tld1.ultradns.net ud1.ns.net.ua
204.74.113.1:	tld2.basicfusion.net tld2.ultradns.net

Statistics
==========
Number of gTLDs:                 15
Number of ccTLDs:               245
Total number of TLDs:           260

Number of IPv4 hosts:           798
Number of IPv4 addresses:       798

Number of IPv6 hosts:            40
Number of IPv6 addresses:        41
TLDs with IPv6 glue:             50

Total TLD name server hosts:    797


-- 
Doug Barton
General Manager, The Internet Assigned Numbers Authority