ccNSO comments on Technical Checks Used for DNS Root Zone Changes

["Chris Disspain" <ceo@xxxxxxxxxxx>]

ccNSO comment to IANA consultation
----------------------------------
 
This document is a ccNSO comment to the IANA/ICANN paper sent the 18th of 
August: "Comments Sought on Technical Checks Used for DNS
Root Zone Changes", see:
http://www.icann.org/announcements/announcement-18aug06.htm
 
This document was prepared by the ccNSO IANA Working Group and has been open 
for comment by members of the ccNSO.
 
The Country Code Names Supporting Organization (ccNSO) is the policy 
development body for a narrow range of global ccTLD issues
within the ICANN structure, see: http://ccnso.icann.org/
 
The ccNSO IANA Working Group is the working group set up by the to improve the 
service and communication that IANA provides to
ccTLDs,
see: http://ianawg.ccnso.org <http://ianawg.ccnso.org/> .
 
The IANA WG mandate is available here:
http://ianawg.ccnso.org/pub/IANAWG/WebHome/cc-0001.pdf
 
ccTLD concerns considered by the IANA WG are listed here:
http://ianawg.ccnso.org/pub/IANAWG/WebHome/cc-0000.txt
 
 
Summary:
 
-         This open consultation is a good approach and the proposed IANA paper 
is a good starting point;
-         A simple, light and reliable process must be implemented, remembering 
that the IANA service is more critical than
operationally heavy;
-         We welcome and encourage IANA to pursue its objective to implement a 
more automated process for root zone management but
strongly recommend that there is a full evaluation of the potential impact this 
could have on security;
-         We recommend work on a single list of technical requirements without 
specific references to who is checking what;
-         We stress that local registries might need to implement specific NS 
configurations to respond to local needs or
constraints;
-         IANA technical systems must not prevent ccTLD operators from managing 
the registry in accordance with their local needs,
constraints or strategies as long as they are technically valid. 
 
Background:
----------
 
Technical Checks performed before DNS Root Zone Changes was identified by the 
IANA WG as one of the main concerns for ccTLDs, see:
http://ianawg.ccnso.org/pub/IANAWG/WebHome/cc-0000.txt
 
In November 2005, IANA provided the IANA WG with a factual description of the 
current technical checks performed for DNS Root Zone
Changes.
This document is available here:
http://ianawg.ccnso.org/pub/IANAWG/WebHome/cc-0003.pdf
 
Doc summary (ianawg ref):
 
cc-0003 :IANA Technical Checks:nov 2005:iana documentation:000003
        :IANA Technical checks:may 2006: acknowledged
        :[description of current IANA procedures to checking NS upon ccTLD 
request]
 
In June 2006, IANA posted to the group a "discussion paper on suitable 
technical checks for root zone entries", see:
http://ianawg.ccnso.org/pub/IANAWG/WebHome/cc-0012.pdf
 
Doc summary (ianawg ref):
 
cc-0012 :discussion paper on suitable technical checks for root zone entries
        :jun 2006:iana documentation:000038
        :IANA technical checks-ccTLD test and procedures:jul 2006
        :under 
consideration:[http://www.icann.org/announcements/announcement-18aug06.htm]
 
ccNSO position:
----------------
 
Having considered the issues, the ccNSO view can be summarised as follows:
 
1.there is a consensus that IANA must not perform checks that are not really 
necessary: the number of checks should be minimised,
focusing on efficiency, security and appropriate NS management ;
 
2.although discussions are still in progress on specific matters, a
set of requirements for TLD   zones and their authoritative name
servers to be announced by the root have been identified (see below);
 
3.there are other specific technical configurations or features seen as 
requirements by some ccTLDs while others think they should
not be seen as such. If checks were performed on those, they could be reported 
should they fail, but shouldn't block a request for
root zone modification.
 
List of technical requirements for ccTLD operators:
---------------------------------------------------
 
The following set of specific requirements have consensus:
 
- Registry servers MUST be authoritative (bit 'aa');
 
- Registry servers MUST respond to TCP 53 connections;
 
- The list of NS announced (or to  be announced) by the root MUST be
  consistent with the list of NS announced by the authoritative
  registry servers themselves;
 
- A response from the root to a query for a ccTLD MUST fit into
  512 bytes;
 
- The IP addresses announced by the root (or to be announced) for each
  NS MUST be consistent with IP address announced by the authoritative
  NS themselves (*);
 
(*) On this last requirement, it was highlighted that the glue issue
    needed further consideration. In principle, root servers should
    not announce IP addresses unless necessary for resolutions ;
 
Other requirements perceived as necessary by some and not by others include:
 
- minimum number of name servers, minimum number of networks (some
  think that two name servers is for example a good minimum safeguard
  which is not really constraining for registry operators, other argue
  that anycast changes the rule as with anycast one IP address can
  have any number of servers behind it);
 
- minimum number of servers responding to DNS queries (some suggest
  that all authoritative NS servers for a TLD should respond to TCP NS
  queries, other think that if the minimum number of required NS is
  reached, this is enough);
 
- Registry NS must not be recursive in principle, but it seems that
  this shouldn't be a IANA requirement;
 
Moving forward:
---------------
 
The 18th of August, ICANN launched a public consultation called "Comments 
Sought on Technical Checks Used for DNS Root Zone
Changes":
 
http://www.icann.org/announcements/announcement-18aug06.htm
 
Here are our comments on this paper:
 
General comment:
----------------
 
We welcome IANAs work on this important issue that directly impact the services 
ccTLDs get from IANA: this initiative is a good
approach, the proposed paper is a good starting point.
 
We also welcome and encourage IANA to pursue its objective to implement a more 
automated process for root zone management.
 
However we strongly recommend that there is a full evaluation of the potential 
impact this could have on security, as well as on the
day to day communication with ccTLDs and on the service management. We suggest, 
in principle,  a simple, light and reliable process,
remembering that the IANA service is more critical than operationally heavy.
 
ccTLDs would prefer to see at this stage one single document listing technical 
requirements for TLD present in the root without
specific reference to who is performing what. We highlight that, in the end, 
IANA is the only operational party available to ccTLD
for root zone changes.
 
Finally, we highlight that local registries might need to implement specific NS 
configurations to respond to local needs or
constraints.
These ways of offering the DNS service locally might not be usual, but 
perfectly valid and relevant, without generating any risk for
the rest of the community; we do not want to see an IANA technical system that 
would lead to a situation where those ccTLD operator
are not in a position to manage the registry in accordance with their local 
needs, constraints or strategies.
 
 
Specific comments on IANA propositions:
 
> 1.  There must be at least two name servers supplied, and they must
>      not share the same IP address.
 
Some ccs agree believing that is a good safeguard, while others suggest this be 
considered in the light of anycast (see previous
section 2: "List of technical requirements for ccTLD operators")
 
> 2.  There must be no more than 13 name servers supplied.
 
Yes, but NS list including their IP(s) fitting in 512 bytes is also important.
 
> 3.  The supplied hostnames for the authoritative name servers must
>     be fully qualified domain names, with labels no longer than 63
>     octets.
 
Yes, although work must be done to clarify in a single document what a "fully 
qualified domain name" is from a root zone view.
 
> 4.  The supplied authoritative name servers should be verifiably
>     reachable over the public Internet....
 
Yes. Some ccTLDs believe however that as long as the minimum number of required 
DNS server are responding (2 according to IANA), it
should be enough as a formal requirement.
 
> 5.  In response to a query for the SOA record for the top-level
>     domain, each of the supplied authoritative name servers must
>     respond with a DNS answer with the "AA" bit set. (see RFC 1035,
>     Section 4.1.1)
 
Agreed
 
> 6.  IANA checks that the requested name servers match the "NS"
>     Resource Record set in the children. IANA queries the NS RR-set
>     returned by the authoritative name servers, and compare them to
>     the supplied NS records for the root zone. These should match.
 
Agreed
 
> 7.  IANA checks the A and AAAA records of the authoritative name
>     servers, and compares them to the supplied glue records for
>     inclusion in the root zone. These should match.
 
Agreed, but glue policy for root zone should be clarified (glue inclusion in 
the root zone might not be always required).
 
> 8.  IANA checks if other top-level domains use the supplied glue if
>     the request represents an alteration to the name server's IP
>     address. If the name server hostname is shared, it is not a
>     technical failure per se, but IANA advises the applicant that
>     it requires consensus from all affected parties, and starts a
>     dialogue to check whether or not to proceed. (Note: this
>     particular practice is the subject of a separate forthcoming
>     IANA discussion paper)
 
Agreed, but glue policy for root zone should be clarified
 
> 9.  IANA checks the serial numbers in the SOA records supplied by
>     the authoritative name servers. These should match.
 
Synchronization between authoritative NS for ccTLD zone may be performed in 
many different ways. This doesn't seem to prevent any
operator to publish consistent serials, however quite a few ccs have indicated 
that they do not believe this should be seen as a
requirement.
 
> 10. IANA asks that the name servers be on geographically and network
>     topologically separated networks. IANA currently loosely tests
>     this by querying with the applicant on their network setup should
>     all name servers be in the same "/24" IPv4 range.
 
Some ccs agree, while others ask to consider this in the light of anycast (see 
previous section 2: "List of technical requirements
for ccTLD operators")
 
> 11. Should the request involve completely changing every NS record
>     in the root, IANA asks the requestor to consider staggering the
>     request in two passes such that any unexpected faults might be
>     mitigated.
 
Yes, although it is more the responsibility of the operator to propose the 
appropriate process, highlighting that one pass can be
enough if an appropriate process has been set up by the operator, although in 
other circumstances two passes might not solve certain
problems. We acknowledge this is a difficult issue, we are not convinced that 
this can be solved by an automatic technical check.
 
> 12. Whether the name servers have matching PTR records (both IPv4
>     and IPv6)
 
Server names having matching PTR record is a good practise in many 
circumstances, but not not always: this should not be a
requirement.
 
> 13. Whether the name servers have RFC 1918 addresses. (Note:
>     supplying such an address would ordinarily fail IANA's tests
>     due to unreachability.)
 
see comment below,
 
> 14. Whether the IP addresses are on the list of reserved IP
>     addresses.
 
You certainly refer to this:
http://www.iana.org/assignments/ipv4-address-space and 
http://www.iana.org/assignments/ipv6-address-space
 
see comment below,
 
>  15. Whether the last octet of the name server IP address is 0 or
>      255.
 
Comment for 13,14,15:
 
many things could be seen as requirements, for example the following provided 
address: 194.6r:A.bad:AD:500A would pass those tests.
 
As a general principle, we believe that requirements expressed here should stay 
focused on issues that are really necessary,
repeating a previous recommendation to keep a simple, light and reliable 
process for DNS Root Zone Changes.
 
>  16. Whether the overall length of the name server hostname is less
>      than 128 characters.
 
 
Although the theoretical hostname limit is 255 (rfc1123), 128 doesn't seem to 
be an unreasonable practical limit. However, we think
that this is should not to be seen as a requirement for root zone change.
 
Regards,
 
Chris Disspain
Chair - ccNSO Council 
 
Important Notice - This email may contain information which is confidential 
and/or subject to legal privilege, and is intended for
the use of the named addressee only. If you are not the intended recipient, you 
must not use, disclose or copy any part of this
email. If you have received this email by mistake, please notify the sender and 
delete this message immediately. Please consider the
environment before printing this email.