Review of IANA Root Zone Technical Checks

[Alexander Gall <gall@xxxxxxxxx>]

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
  removed.

  12.  Whether the name servers have matching PTR records (both IPv4
       and IPv6)

  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
  somebody else.

  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
  change request.

- 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
      review process?

   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?

   Always.

   4. How should these technical requirements be implemented in an
      automated environment?

   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.

--
Alexander Gall

 ______ 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
 http://www.switch.ch/network/noc/