[rssac-caucus] possible new work item

[Daniel Migault]

I am also interested in contributing to this work.

BR,
Daniel

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
>



-- 
Daniel Migault
Ericsson
8400 boulevard Decarie
Montreal, QC   H4P 2N2
Canada

Phone: +1 514-452-2160
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20150527/47f35ae0/attachment.html>