Response to questions raised 18-21 August 2006

[Kim Davies <kim.davies@xxxxxxxxx>]

Dear Karl and Peter,

We appreciate the questions you have raised in your responses to the
IANA discussion paper on root zone technical checks. Below are
clarifying comments, and we hope they are useful in formulating your
thoughts.

We think some of the questions highlight the fact the current procedure
is ambiguous, and we donât have clear answers to all the questions. This
is one of the central reasons we are seeking to devise a new procedure
that is explicit in how tests are conducted, and we encourage you to
recommend concrete testing techniques for the future.

With respect to the questions raised:

> Karl Auerbach:
> [13 maximum name servers] Is the concern here that the list of servers will 
> fit into a UDP reply of 512 bytes?

Yes, that is correct. Whilst we donât have a direct test for packet size
at present, we do not permit more than 13 name servers listed in a
request. Furthermore, in the rare circumstance that the number of name
servers approaches 13, we pay special attention to the request and the
size of the resulting packets. So whilst we havenât specifically stated
we check for packet size, we would anticipate identifying it during our
manual evaluation anyhow under current procedure.

> Karl Auerbach:
> Are IDN names to be permitted?

We do not see a reason not to support them, although the storage format
and transactional format would likely use the IDNA format (i.e.
xn--[punycode]) in labels for the foreseeable future.

> Karl Auerbach:
> Are you assuming IPv4 only or is there an IPv6 reachability component to the 
> test?

We test all IPv6 addresses supplied from IPv6 connected hosts.

> Karl Auerbach:
> Is there any concern about path MTU issues (e.g. they are running their 
> server over a last-hop link that runs PPP with an MTU of 256?) And is there 
> any concern that there is at least an adequate provisioning of the access 
> path or some degree of monitoring that path?

We do not currently check for anything like this, but welcome
suggestions on the rationale and implementation needs.

> Karl Auerbach:
> It is possible that a TLD server has multiple IP interfaces and thus might 
> issue replies using a different IP address than the requestor sent the 
> request to. Should there be a concern about this, particularly if the 
> response might come back via an entirely different path?

We do not currently check for anything like this, but welcome
suggestions on the rationale and implementation needs.

> Karl Auerbach:
> Are you checking TCP access as well as UDP?

We only test using UDP queries at present.

> Karl Auerbach:
> What if a server is reachable and such, but is behind a NAT? Is that OK?

As long as the correct response packets are sent to query packets, we do
not presently perform any further identification of the composition of
the network for this test.

> Peter Koch:
> The term "the same IP address" suggests that a "nameserver" is considered a 
> pair of (name, ip-address). In practice, "multihomed" TLD nameservers do 
> exist.  Would those be allowed to share addresses with other servers, 
> multihomed or not, belonging to the same NS RRSet?

For the purposes of our tests, we define a name server as a single host
name, plus one or more IPv4 or IPv6 addresses. It is possible to supply
two or more IPv4 or IPv6 addresses to IANA for including in root zone glue.

At present, we simply verify that we donât have a single IP address or
single host name provided as authoritative for the entire zone.
Repetition of the same IP address amongst the IP addresses provided for
different authorities would pass, as long as this minimum diversity is
present.

> Peter Koch:
> Does "13" refer to nameserver names, i.e., the number of NS RRs (as opposed 
> to total number of A or AAAA RRs)?

The limit of 13 refers to the number of name server names, which we
recognise is not specific enough to address the root need for the
restriction â ensuring the packet size does not exceed 512 bytes.

> Peter Koch:
> Is the total length of the supplied server names and the allowed set of 
> characters also checked? If yes, what are the criteria?

Whilst not formally checked by a specific test, anything approaching the
protocol limit for name size of 253 bytes, or which had characters
outside letters, digits and hyphens, would be scrutinised manually at
present.

> Peter Koch:
> Please clarify the exact properties of the query used in [Test 4], e.g. value 
> of the RD bit, presence of an EDNS0 OPT RR and its content, if applicable.

The RD bit is set to zero, and there is no EDNS0 OPT RR present in the
query.

> Peter Koch:
> The last sentence in [Test 4] uses "it" twice. Please clarify who "it has 
> limited connectivity" refers to.

We have clarified the wording, however âitâ in this context referred to
the DNS server on the IP address under test.

> Peter Koch:
> [Test 5] mentions "supplied authoritative nameservers". Are the tests 
> executed against the/all supplied addresses (a.k.a. "glue") for these servers?

Yes, tests are conducted to the entire set of IPv4 and IPv6 addresses
supplied for the proposed authoritative name servers.

> Peter Koch:
> While [Test 5] has a "must", [Test 4], which this one seems to rely upon, 
> only has a "should". Please clarify the tests' relationship.

On occasion, a requestor may explain the reason that a name server is
unreachable from IANAâs test sites. However, should a name server be
reachable and provide answers, it must answer authoritatively.

> Peter Koch:
> How many/which resolution paths are checked for [Test 7]? 

We currently check all IP addresses from our US test site, and only test
from our additional sites in the event of unreachability. We donât
currently test for inconsistent answers from multiple network locations.

> Peter Koch:
> Is a match [for Test 7] considered successful only when the A or AAAA RRSets 
> exactly match?

At present, the test is for the A and AAAA RR sets matching. If they did
not match we would clarify the situation with the requestor and discuss
the implications. As this is not mandatory, if there was a suitable
reason for the difference, we would allow the requestor to insist to
proceed assuming the request complied with the other criteria.

> Peter Koch:
> What happens if at least one CNAME RR is involved in the resolution?

We do not presently have a procedure for this.

> Peter Koch:
> What list of "reserved IP addresses" (e.g. RFC 3330) is used [in Test 14]? 
> Does the note to [Test 13] apply?

We are unsure, as this test is not conducted by IANA. Weâll seek to
clarify this term. If the IP address under test were unreachable from
our test sites, it would fail reachability tests also.

Thank you for taking the time to read our paper and provide your
valuable advice.

All the best,

Kim Davies
Internet Assigned Numbers Authority