IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data

[Peter Koch <pk@xxxxxxx>]

Please find below my comments to the proposed "IANA Administrative Procedure
for Root Zone Name Server Delegation and Glue Data".

First, I appreciate the proposal as a step forward in supporting the
deployment of IPv6. There are some statements in the proposal that could
benefit from clarification and refinement.
Generally, each step described should have a corresponding "rationale" section
explaining in detail the background and reasons for applying this particular
step or measure. That might address most of the comments below.

IANA Procedures for Processing Name Server Change Requests

1) text: suggest to change "name server record(s)" to "name server(s)". The
     "record" (as in "NS RR") includes the owner, which cannot be mentioned
     in a different TLD's delegation.
   procedure: Please set a timeout, otherwise unresponsive TLD managers
     unrelated to both the nameserver and the TLD in question may slow down
     or stop the process.
   explanation: The rationale seems to be to ensure that all affected parties
     are aware of address changes, which may be important for XFR purposes
     and monitoring. However, I do not see why third party TLDs should
     acknowledge removal or addition of an existing nameserver to a TLD's
     NS RRSet, if the address(es) of that server remain unchanged.
   question: Who is allowed to initiate such change requests? Can a server
     administrator who is not a TLD manager change their nameserver's
     address(es)?

2) --

3) When matching the lists of servers in both the request and the actual
   operational TLD, the proposal says "the authoritative" servers will be
   checked. While I agree that this is good practice, shouldn't it read
   "the to be authoritative servers" to make sure or emphazise, respectively,
   the to be delegated servers are checked, too?

4) It is rather obvious but the proposal does not demand that all servers
   return an authoritative answer for the SOA in response to a non-recursive
   query. Speaking of SOA values, it is worth mentioning that the system
   named in the MNAME field need not be part of the NS RRSet and need not be
   accessible. Consequently, the reference to the master/primary is
   questionable, since that might not be known. On the other hand, if all
   SOA RRs match (their RDATA matches), they'll match what the primary
   returns or would return. Suggest to remove the reference to the primary.

5) The size of the response heavily depends on the length of the query.
   Suggest to use worst case query length (255 octet QNAME) or document
   which sizes are used and why.
   Even less than eight name servers or addresses may lead to larger sizes
   than 512 octets, depending on the lengths of the name server names and
   subject to their compressibility. 
   Reference to modern (i.e. EDNS0-aware) software is OK, but not only
   availability but significant deployment on the resolver side is a
   prerequisite for relaxing the 512-octet-rule.

In addition to step (1) I suggest to check that the name server names do
resolve to the address(es) supplied with the change request, both for IPv4
and IPv6 addresses. Inconsistencies should be reported to the TLD administrator.

The root zone traditionally applies a glue policy different from that of many
TLDs in that a "glue record" is required for every nameserver regardless of
whether or not it resides in the zone delegated to it. While this "courtesy
glue" (or simply additional information) may increase efficiency it is,
strictly speaking, not necessary in all cases. Whenever the maximum size of
a response packet is calculated, this should be taken into acount.

These comments do not cover the second part of the proposal, called
"IANA Procedures for removing Problematic Delegation Data".

-Peter