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