[rssac-caucus] possible new work item

[Warren Kumari]

[ Top-post ]

Gulp. What, someone gave you a worm can opener for your birthday?!

Yah, this sounds fun / interesting. If a work party if formed I'd like
to participate....

W

On Tue, May 19, 2015 at 12:16 PM, 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf