[rssac-caucus] possible new work item

[Brian Dickson]

tl;dr: Yes, I like it, and volunteer to participate.

Brian

On Tue, May 19, 2015 at 9:16 AM, Joe Abley <jabley at hopcount.ca> wrote:
> 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.
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus