Re: [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
Doug, thank you very much for your detailed reply to the followup questions I asked on behalf of the WG. Speaking in a personal capacity, I think it would be helpful if IANA would consider a different course of action if an incident like this pops up again. Although there are all sorts of difficult value judgements to be made -- many of them political rather than technical -- it may be better to err on the side of openness and transparency. That reduces the potential for confusion. Or, in the context of this recent problem, it prevents the perception that some sort of policy change has been made behind closed doors. It's now up to the WG to respond to your reply Doug. If there are no substantive comments or questions in the next week or so, I suggest we consider this matter resolved.
On Fri, 10 Jun 2005, Doug Barton wrote:
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.
In the interests of further explanation and clarification, I'd like to add some details of these events from VeriSign's perspective. First, to be clear, the VeriSign registry database that generates the root zone has supported multiple name server names (i.e., A records) with the same IP address for some time. There was never a technical restriction on multiple names with the same IP address during these events. On November 11, 2005, VeriSign performed a root zone edit as requested by an IANA Name Server Change template for the .FR ccTLD. The template requested name server NAME changes. A request to change the name DNS.PRINCETON.EDU. was included in the template. As a result of the execution of the change, the name DNS.PRINCETON.EDU did not exist and had been replaced by C.EXT.NIC.FR. Considering the template semantics, this was the correct result. It was not, however, the result that IANA desired. After VeriSign discovered the undesired results, DNS.PRINCETON.EDU was immediately re-added to the root zone by ADDing a new name server. In retrospect, it is apparent that the correct way to accomplish the original request would have been to request a new server ADD for C.EXT.NIC.FR, and then to delegate .FR to it while leaving the older name server DNS.PRINCETON.EDU untouched, and thus leaving delegations of BI, CH, HT, LI, and LU untouched. Below is an example of a preferred template semantic for a name server NAME change, followed by the original template as it arrived: New/GOOD: ************************************************************ CCTLD MODIFICATION TEMPLATE v.1.3 1. Purpose/Description.............: Add 7 name servers, add an IPv6 address for 1 name server and remove 6 name servers 2. Top-Level Domain Name...........: .fr 3. Sponsoring Organization [no change] 4. Administrative Contact [no change] 5. Technical Contact [no change] Primary Name Server [add primary nameserver] 6a. Primary Server Hostname.........: A.NIC.FR 6b. Primary Server Netaddress.......: 192.93.0.1 [remove NS1.NIC.FR from delegation] Secondary Name Server [add secondary nameserver] 7a. Secondary Server Hostname.......: B.NIC.FR 7b. Secondary Server Netaddress.....: 192.93.0.4 7c. Secondary Server Netaddress.....: 2001:660:3005:1::1:2 [remove NS2.NIC.FR from delegation] Secondary Name Server [no change] 7a. Secondary Server Hostname.......: C.NIC.FR 7b. Secondary Server Netaddress.....: 192.134.0.49 7c. Secondary Server Netaddress.....: 2001:660:3006:1::1:1 Secondary Name Server [add secondary nameserver] 7a. Secondary Server Hostname.......: A.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 193.51.208.13 [remove DNS.INRIA.FR from delegation] Secondary Name Server [add secondary nameserver] 7a. Secondary Server Hostname.......: B.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 128.105.2.10 [remove DNS.CS.WISC.EDU from delegation] Secondary Name Server [add secondary nameserver] 7a. Secondary Server Hostname.......: C.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 128.112.129.15 [remove DNS.PRINCETON.EDU from delegation] Secondary Name Server [add secondary name server] 7a. Secondary Server Hostname.......: D.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 204.152.184.85 7c. Secondary Server Netaddress.....: 2001:4f8:0:2::8 Secondary Name Server [add secondary name server] 7a. Secondary Server Hostname.......: E.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 193.176.144.6 REMOVE: NS-EXT.VIX.COM (204.152.184.64) from delegation ************************************************************ Old/BAD: ************************************************************ CCTLD MODIFICATION TEMPLATE v.1.3 1. Purpose/Description.............: Change the hostname for 5 name servers, add 2 name servers, add an IPv6 address for 1 name server and remove 1 name server 2. Top-Level Domain Name...........: .fr 3. Sponsoring Organization [no change] 4. Administrative Contact [no change] 5. Technical Contact [no change] Primary Name Server [change the hostname and add GLUE] 6a. Primary Server Hostname.........: A.NIC.FR 6b. Primary Server Netaddress.......: 192.93.0.1 [previous hostname was NS1.NIC.FR] Secondary Name Server [change the hostname, add IPv6 address, add GLUE] 7a. Secondary Server Hostname.......: B.NIC.FR 7b. Secondary Server Netaddress.....: 192.93.0.4 7c. Secondary Server Netaddress.....: 2001:660:3005:1::1:2 [previous hostname was NS2.NIC.FR] Secondary Name Server [no change] 7a. Secondary Server Hostname.......: C.NIC.FR 7b. Secondary Server Netaddress.....: 192.134.0.49 7c. Secondary Server Netaddress.....: 2001:660:3006:1::1:1 Secondary Name Server [change the hostname and add GLUE] 7a. Secondary Server Hostname.......: A.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 193.51.208.13 [previous hostname was DNS.INRIA.FR] Secondary Name Server [change the hostname and add GLUE] 7a. Secondary Server Hostname.......: B.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 128.105.2.10 [previous hostname was DNS.CS.WISC.EDU] Secondary Name Server [change the hostname and add GLUE] 7a. Secondary Server Hostname.......: C.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 128.112.129.15 [previous hostname was DNS.PRINCETON.EDU] Secondary Name Server [add secondary name server] 7a. Secondary Server Hostname.......: D.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 204.152.184.85 7c. Secondary Server Netaddress.....: 2001:4f8:0:2::8 Secondary Name Server [add secondary name server] 7a. Secondary Server Hostname.......: E.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 193.176.144.6 REMOVE: NS-EXT.VIX.COM (204.152.184.64) ************************************************************ VeriSign has taken action to avoid this situation in the future. We have shared details of this incident with all relevant VeriSign personnel and alerted them that we should watch for name server NAME changes and not execute them literally. That is, a name server name "change" should not actually be a change, but we should interpret that a name server name change is really a name server name "add." We consider this a temporary fix for the ambiguous name server name change template. The long-term fix should be a less ambiguous name server name change template. To that end, we have opened a discussion with IANA regarding the format and semantics of the root zone change template. Matt -- Matt Larson <mlarson@verisign.com> VeriSign Naming and Directory Services
On Wed, 15 Jun 2005 09:50:06 -0400, Matt Larson <mlarson@verisign.com> said:
On Fri, 10 Jun 2005, Doug Barton wrote:
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.
In the interests of further explanation and clarification, I'd like to add some details of these events from VeriSign's perspective.
First, to be clear, the VeriSign registry database that generates the root zone has supported multiple name server names (i.e., A records) with the same IP address for some time. There was never a technical restriction on multiple names with the same IP address during these events.
On November 11, 2005, VeriSign performed a root zone edit as requested by an IANA Name Server Change template for the .FR ccTLD. The template requested name server NAME changes. A request to change the name DNS.PRINCETON.EDU. was included in the template. As a result of the execution of the change, the name DNS.PRINCETON.EDU did not exist and had been replaced by C.EXT.NIC.FR. Considering the template semantics, this was the correct result. It was not, however, the result that IANA desired. After VeriSign discovered the undesired results, DNS.PRINCETON.EDU was immediately re-added to the root zone by ADDing a new name server.
I think the problem is that VeriSign uses the concept of name server objects (probably the same model they use for their TLD registries) and IANA doesn't. To IANA, the template simply represents the complete delegation (or maybe only the things that actually changed) for a single TLD, changes of which are not supposed to affect the state of any other TLD. When the template says "remove server <x> for TLD <y>", IANA actually means "remove the NS record for <y> and possibly the glue RR for <x> if no other TLD is referencing it", while VeriSign apparently just deletes the name server object. Not quite the same thing.
In retrospect, it is apparent that the correct way to accomplish the original request would have been to request a new server ADD for C.EXT.NIC.FR, and then to delegate .FR to it while leaving the older name server DNS.PRINCETON.EDU untouched, and thus leaving delegations of BI, CH, HT, LI, and LU untouched.
It's not at all apparent to me. I don't think this is ncessary and that the template is well-defined without any additional instructions on how to manipulate name servers. It's simple: after the template has been processed (possibly merging it with the previous set of name servers if it only contains diffs), the TLD in question must have NS records for all the "Server Hostname" entries in the template and appropriate A/AAAA glue for each one of them. This is unambiguous and doesn't affect any other TLDs. How VeriSign maps this to their database model is up to them and should not be exposed to the outside. I believe that this is what IANA is expecting, and, frankly, it sounds very reasonable and clear to me. I'm baffled (actually, I'm shocked :-) that such a major misunderstanding could go undetected for so long. -- Alex
participants (4)
-
Alexander Gall -
Doug Barton -
Jim Reid -
Matt Larson