Review of IANA Root Zone Technical Checks
- To: techcheck-comments@xxxxxxxxx
- Subject: Review of IANA Root Zone Technical Checks
- From: Alexander Gall <gall@xxxxxxxxx>
- Date: Fri, 29 Sep 2006 17:19:06 +0200
As the operator of two ccTLDs (ch and li), we mostly agree with the
technical comments on the tests themselves that have been made so far.
A few additional remarks:
10. Minimum network diversity.
Apart from the problem that there is no natural way to specify what
is "diverse enough", this involves either second-guessing what the
operator is doing or requires IANA to analyze potentially complex
configurations of the applicant's network and name servers, which is
either hard or impossible to automate. This check should be
12. Whether the name servers have matching PTR records (both IPv4
This fails for example in the fairly common case when a TLD operator
duplicates A/AAAA records to create "uniform names" that can be
compressed efficiently, whose inverse mappings are controlled by
15. Whether the last octet of the name server IP address is 0 or 255.
These addresses are not unusable a priori.
Whether non-compliance to some of these tests should block a change
request is probably a fairly controversial issue. In our opinion, all
checks should be informational only. An exception to this could be
requirements for the information that is actually stored in the root
zone (e.g. checks 1, 2, 3), because that's the only thing under direct
control of IANA.
Here are a few arguments in favor of this:
- There is no way to force a TLD to comply to these checks at all
times unless IANA has the power to sanction the operator, which
isn't going to happen at least for those TLDs that don't have any
contracts with ICANN (i.e. most ccTLDs). Given that change requests
happen pretty rarely, it is questionable whether enforcing
compliance only on these occasions can substantially improve the
quality of the TLD's DNS service.
- It will be very hard to agree on the set of tests that can block a
- Some observations can depend on the location from where they are
conducted, i.e. such test results are not necessarily representative
for the Internet at large.
As a general rule, all tests should be fully automated (and simpler
tests are easier to automate).
To answer the questions specifically:
1. Which technical requirements should be mandatory for TLD
operators to comply with in order for changes to be accepted in
the DNS root?
None or a very restricted set like checks 1, 2 3.
2. Which issues should be highlighted as warnings by the technical
Issues related to name server configurations that can be specified
precisely, e.g. checks 5, 6, 7, 8, 9 but not 10.
3. Under which circumstances should these warnings be allowed to
advance if the TLD operator wishes to still proceed?
4. How should these technical requirements be implemented in an
This seems straight forward if the checks themselves can be
automated. I'm not sure I understand the issue here.
5. What role, if any, should IANA play in the ongoing verification
of compliance by TLD operators to minimum technical standards?
Periodic checks can be useful. As a service, IANA could inform the
technical contact if something looks bad, but this should be
configurable. Personally, I wouldn't mind if the results of these
periodic checks would be accessible publically.
______ SWITCH - The Swiss Education and Research Network _______
SWITCH NOC, Limmatquai 138, CH-8001 Zurich, Switzerland
noc@xxxxxxxxx Tel: +41 1 268 1530 Fax: +41 1 268 1568