[dns-wg] Followup to IANA TLD delegation problem

On Wed, 15 Jun 2005 09:50:06 -0400, Matt Larson <mlarson at 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