[rssac-caucus] possible new work item

[Joe Abley]

Hi all,

I have a suggestion for a new work item for RSSAC. If RSSAC thinks this 
work would be of value, and there are people willing to work on it, I'd 
be happy to (co-) lead a work party.

A rough sketch of a charter follows.

Comments would be most welcome!

Thanks,


Joe


Back in the dim mists of time, individual root servers had names chosen 
by the organisation that operated them. Some/all of these names are 
recorded for posterity in the canonical root hints file, e.g. A was 
originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was 
originally NS.ISC.ORG, etc.

   ftp://rs.internic.net/domain/named.cache

The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, 
with the intent that the response to the priming query (using label 
compression for the ROOT-SERVERS.NET domain) would be smaller, and would 
allow an additional four root servers to be specified without causing 
the priming response to grow beyond the specified non-EDNS(0) message 
size limit using UDP transport. I have seen this cleverness attributed 
to Bill Manning in the past.

ROOT-SERVERS.NET was delegated from the NET zone to all root servers. 
The domain exists in the NET registry, defended by a platoon of registry 
locks, and the zone itself is (if I recall correctly) maintained and 
distributed by Verisign to root server operators as part of the root 
zone maintainer function, with changes following a similar process to 
that used for the root zone, including interactions between the three 
root zone partners.

In the opinions of some (but not all) people, the existence of the 
ROOT-SERVERS.NET zone is a historical mistake, and it would have been 
better to name the root servers in a way that avoided the necessity for 
a separate zone, e.g. bare single-label names (A, B, C, ...) or 
multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) 
provisioned directly in the root zone.

The presence of a label like ROOT-SERVERS might in effect constitute a 
reserved TLD label, with corresponding impact on ICANN policy for root 
zone management, the technical direction and remit of the IETF/IAB, and 
the intersection of the two. So, there are dragons^Wpolitical 
considerations, although I think RSSAC should constrain itself to 
technical commentary and leave any dragon baiting to others.

SAC53 has a thing or two to say about "dotless domains" like A, B, C, 
etc which could no doubt provide a useful citation. A client that sends 
a priming query with EDNS0.DO=1 (which, I gather, is how most priming 
queries are observed to arrive today) does not currently receive a 
response with signatures in the additional section of the response, 
because the ROOT-SERVERS.NET zone is not signed. The lack of signatures 
in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on 
your perspective; if it was to be signed, the question of key management 
would arise. If signatures were present, there might be some operational 
impact caused by the increased size of the priming response.

Rather than the naming scheme for root servers remaining a collection of 
partially-remembered anecdotes plus occasional yet regular memes on 
mailing lists about what a mistake the current naming scheme was, I 
think it would be good if RSSAC could produce a document that:

1. Provides a citeable history on how root nameservers were originally 
named and how they are named today, recording the reasons for the 
change;

2. Considers the risks and benefits of a new naming scheme that avoids 
the zone cut, including impact on root zone partners' processes, on 
operational issues like priming response sizes and backed-in assumptions 
elsewhere about root server names and on security issues relating to 
DNSSEC validation;

3. Considers the risks associated with any transition from the current 
naming scheme to a different one;

4. Makes recommendations as to whether a change from the current scheme 
should be made and, if the recommendation is to make a change, makes 
further recommendations that might frame the way a transition is planned 
and managed operationally. A recommendation that there be no change is 
an equally reasonable outcome; either way the document should include 
high-quality justification and reasoning.

All recommendations made would be actionable by ICANN (rather than 
recommendations actionable by the other two partners or anybody else 
with skin in the game), since that is the scope of our role.