Nominet's Comments on Technical Checks Used for DNS Root Zone Changes

[Geoffrey Sisson <geoff@xxxxxxxxxxxxxx>]

                Nominet's Response to IANA's Request For
             Comments on Root Zone Change Technical Checks

                           30 September 2006


Preface
-------

Nominet welcomes the opportunity to respond to IANA's request for
comments, "Comments Sought on Technical Checks Used for DNS Root Zone
Changes", dated 18 August 2006 (modified 21 August 2006):

    http://www.icann.org/announcements/announcement-18aug06.htm

We are pleased to see IANA taking steps to be more proactive in
addressing the needs of TLD operators and in inviting stakeholder
comments on IANA policies and procedures prior to enacting changes to
them.

Nominet has made numerous requests for root zone changes for the .uk
TLD over the last 10 years.  Our experience with change requests has
been generally positive: IANA has nearly always responded efficiently
and courteously, and effected the changes without undue delay.  The
comments that follow should not be interpreted as criticism of IANA
but only as suggestions for improvements to, and modernisation of,
IANA's current policies and procedures.


Significant Meta Issue
----------------------

We would like to identify what we believe to be a significant meta
issue with this consultation.  The announcement states:

    IANA is seeking to review its practices associated with the
    technical checks it performs on data provided by top-level domain
    operators for inclusion in the root zone.

However, it is clear that these practices are implicitly and
inextricably linked to IANA technical policy.  Consequently, comments
on these practices will in effect be comments on a subset of IANA
technical policy.

To put it another way, this consultation conflates root management
policy with methods for technical checks, to its detriment.

For purposes of the current review, we confine our remarks to the
specific issues that arise from IANA's root zone checks.  However, we
strongly believe that there should be a subsequent broader review of
IANA technical policy, particularly as it relates to the management of
the root zone.


General Observations
--------------------

We observe that there are two related but not identical purposes that
are served by IANA's technical checks:

1.  To avoid conditions which could have an adverse impact on the
    global Internet or to significant parts of the DNS external to the
    requesting TLD.

2.  To avoid conditions which could have an adverse impact confined
    principally to the requesting TLD.

As an illustration of the first case, if all the name servers for a TLD
stop responding, the consequence will be an increase of traffic to the
root servers.  If the TLD is one that receives substantial query
traffic, then the unreachability of the TLD's name servers may create
dramatic or even catastrophic increases in traffic to the root
servers.

On the other hand, if a single name server for a TLD stops responding,
then the effects of this failure are generally confined to that TLD.
While the query load on the remaining name servers will increase and
the resolution of names within the TLD may take longer, the resolution
of names outside of the TLD will generally not be significantly
affected.

IANA makes a distinction between "mandatory requirements" and
"recommendations".  We believe that, as a guiding principle, tests for
conditions which have implications for the global DNS should correspond
to "mandatory requirements" while tests for conditions which have
implications for the TLD should reflect "recommendations".

This principle need not be applied without flexibility.  For example,
some potential errors that would affect the requesting TLD only are so
obviously undesirable that there would be no reasonable justification
for a TLD to insist upon them.  These, too, might then be classified as
"mandatory requirements".

Based on these guidelines, Nominet believes that it is correct for IANA
to prevent changes that would violate "mandatory requirements" and to
intervene in changes that are inconsistent with "recommendations", but
that, in the latter case, IANA should not unreasonably withhold or
delay approval.  In other words, IANA should take care to act as a
custodian of the Internet and not as the Internet police.


Comments on Current IANA Tests
------------------------------

Test 1: Minimum number of name servers

    We agree that this should be a "mandatory requirement" but that it
    should be modified to permit a TLD to specify a single name server
    provided that it is an anycasted name server with at least two
    global nodes.

    While it is normally not difficult for a TLD to provide a second
    name and IP address for an anycast instance, we believe that
    requiring them to do so is an artificial constraint that does
    nothing to improve security or stability.

Test 2: Maximum number of name servers

    We believe this test is insufficient.  It appears to be intended
    to limit the size of the payload in DNS responses to fewer than
    512 octets.  However, we believe that response size can and should
    be tested irrespective of the number of name servers, and we
    propose such a test below (see "Proposed Test 2") in place of
    this one.

Test 3: Hostname validity

    We agree that this should be a "mandatory requirement".  Note also
    that the name server name should be tested to ensure its wire
    format representation does not exceed a length of 255 octets.

    We also believe it should be a "mandatory requirement" that a name
    server name be a valid "host name", i.e., conform to the syntax
    specified in Section 3.5 of RFC 1034.  This mitigates the
    deleterious effects of some obsolete or broken DNS implementations.

    We also believe it should be a "mandatory requirement" that a name
    server name be in a TLD that exists in the root zone; it must not
    be in a TLD that exists only on so-called "alternate root" servers
    or in a TLD that does not exist at all.  While such name servers
    would normally fail reachability tests, this should not be
    considered a certainty.

Test 4: Name server reachability

    We agree that it should be a "mandatory requirement" for the name
    servers to be "reachable over the public Internet".  It may be
    desirable to formalise the testing methodology.  Ideally, this test
    would be performed using a larger population of topologically
    distinct hosts that would be more capable of accurately identifying
    reachability problems.

    One way to do this would be to test connectivity through a widely
    distributed network of hosts, such as those used by RIPE NCC's Test
    Traffic Measurement (TTM) Service.

Test 5: Name server authority

    We agree that this should be a "mandatory requirement".  We believe
    this should be broadened to require that the AA bit is set in all
    negative replies for nonexistent DNS names in the TLD.

Test 6: Name server coherency

    We agree that this should be a "mandatory requirement".

Test 7: Glue coherency with hostname

    We agree that this should be a "mandatory requirement".

Test 8: Glue coherency with existing glue.

    We agree that this is a reasonable interim approach, but that this
    should be fully reviewed as part of a comprehensive review of IANAs
    glue policy for the root zone.  (See section on "Use of Glue"
    below.)

Test 9: Serial number coherency

    Many TLDs now dynamically update the contents of their zones, so
    serial numbers may change rapidly, making it difficult or even
    impossible to establish serial number consistency.  Depending on
    the method used to update the zone, it is possible that serial
    numbers will rarely or never match.  Consequently, we strongly
    recommend that this requirement should be dropped altogether.
    It should not be a "mandatory requirement" or even a
    "recommendation".

Test 10: Minimum network diversity test

    Only the minimum number of name servers should be required to be
    "diverse".  In other words, if a TLD has three name servers, two on
    one network and one on another, then we believe the minimum
    requirement for diversity is met.

Test 11: Name server continuity

    We believe this a reasonable "recommendation".  We do not believe
    it should be a "mandatory requirement", as a TLD may wish to change
    all name servers at once, either in an emergency where the IP
    addresses of the previous name servers are unreachable (and timely
    resumption of service is unlikely) or where the TLD is disused and
    no one will be affected by such a change.


Comments on VeriSign Tests
--------------------------

It is unclear from the consultation whether IANA considers any or all
of these tests to be "mandatory requirements".

We cannot see any reason for there to be any test associated with a
mandatory requirement or a recommendation that is performed by VeriSign
but not IANA, unless some specific aspect of VeriSign's infrastructure
is required for the tests.  We think all tests should be performed
by IANA or as subcontractors to IANA.

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

    We believe there is no reason to require name servers to have
    corresponding PTR resource records and that this should be a
    "recommendation" rather than a "mandatory requirement".

Test 13: Whether the name servers have RFC 1918 addresses

    It should be a "mandatory requirement" for a requested name server
    not to have an IPv4 address in the private address space defined in
    RFC 1918 Section 3.  Note that this test is superseded if Test 14
    is implemented according to our suggestion.

Test 14: Whether the IP addresses are on the list of reserved IP
    addresses

    It is unclear which "list of reserved IP addresses" is being
    referred to; however we suggest the following as "mandatory
    requirements":

    An IPv4 address must 1) be in a valid allocated address block in
    the IANA "Internet Protocol Version 4 Address Space" allocation
    table (http://www.iana.org/assignments/ipv4-address-space) and
    2) not be in any of the reserved networks listed in RFC 3330.

    An IPv6 address must 1) be in a valid allocated address block in
    the IANA "Internet Protocol Version 6 Address Space" allocation
    table (http://www.iana.org/assignments/ipv6-address-space) and
    2) not be in the reserved network listed in RFC 3849.

Test 15: Whether the last octet of the name server IP address is 0 or 255

    We agree that this is a reasonable "mandatory requirement".  While
    no standards are violated by such IP addresses, we recognise that
    this requirement serves to mitigate the possible deleterious
    effects of broken or misconfigured "middle boxes" (firewalls,
    routers, etc.) and that avoiding the use of such IP addresses
    represents a negligible imposition on TLD operators.

Test 16: Whether the overall length of the name server hostname is less
    than 128 characters

    We believe this is a completely arbitrary requirement and should
    be dropped.  It should not even be a "recommendation".


Proposed Additional Tests
-------------------------

We believe the following requirements and recommendations should be
added:

Proposed Test 1: TCP

    It should be a "mandatory requirement" for all TLD name servers to
    provide valid DNS responses to TCP queries as well as UDP queries.

Proposed Test 2: Maximum DNS Payload Size of DNS Responses.

    It should be a "mandatory requirement" that the number and size of
    resource records held in the root zone for a TLD be sufficiently
    small that the DNS payload of a non-DNSSEC referral response for
    the TLD will not exceed 512 octets for any query.  It must be taken
    into account that a query may contain a QNAME of up to 255 octets
    which then must be returned in the QUESTION section of the
    corresponding response.

Proposed Test 3: Negative Caching

    It should be a "mandatory requirement" for all negative non-DNSSEC
    responses to contain the SOA resource record (RR) of the TLD so
    that negative caching [RFC 2308] may be facilitated.  (Negative
    DNSSEC responses need not contain an SOA RR as the TTL of the NSEC
    RR may be used as the negative cache value.)

Proposed Test 4: Minimum TTLs

    It should be a "mandatory requirement" for all NS resource records
    (RRs) at the apex of a TLD zone to have TTLs of no less than
    five minutes (300 seconds) and for all of the A RRs associated with
    those NS RRs to similarly have TTLs of no less than five minutes
    (300 seconds).

    It should be a "recommendation" for all NS RRs at the apex of a TLD
    zone to have TTLs of no less than one day (86400 seconds) and for
    all of the A RRs associated with those NS RRs to similarly have
    TTLs of no less than one day (86400 seconds).

Proposed Test 5: Source IP Address of Responses

    It should be a "mandatory requirement" that DNS responses from a
    TLD's name servers contain the same source IP address as the ones
    in the destination IP address of the corresponding DNS queries.

Proposed Test 6: Open Recursive Name Service

    It should be a "mandatory requirement" that no name server for a
    TLD may be an open recursive name server.

Proposed Test 7: SOA MINIMUM value

    It should be a "recommendation" that the MINIMUM field of the SOA
    resource record for a TLD should have a value of no less than 15
    minutes (900 seconds).  This serves to reduce the number of resent
    queries for nonexistent names in the TLD via negative caching.

Proposed Test 8: EDNS0

    It should be a "recommendation" that EDNS0 is enabled on all name
    servers for a TLD, and that a payload size of at least 2048 octets
    is supported.


Use of Glue
-----------

We believe that IANA's glue policy for the root zone should be the
subject of a full review.  Currently, the root zone utilises what might
be described as a "wide glue" policy: the A resource records for all
TLD name servers are included in the root zone, even if the DNS name of
the name server is in a non-child descendant zone.  This appears to be
a legacy policy that has been carried forward without critical scrutiny.


Periodic Checks
---------------

We believe that it makes sense to implement many of the previously
described checks as periodic checks.  We suggest that it is premature
to make specific recommendations as to the frequency of these checks,
or the precise consequences of failed checks; this discussion should
wait for the outcome of a broader review of IANA technical policy.


Summary
-------

Nominet believes that this consultation is a positive and welcome first
step.  However, we stress that it is not a substitute for a full review
of IANA technical policy for the management of the root zone.
Nevertheless, we have provided comments that we hope IANA will find
useful preparing for the development of such policy.



Geoffrey Sisson
Jay Daley
Roy Arends