[rssac-caucus] 答复: possible new work item

[王伟]

Dear Joe

I think this work do make sense and should be fun
I'd like to join the team if the work party formed.


Regards
Wesley WANG, ZDNS


-----邮件原件-----
发件人: rssac-caucus-bounces at icann.org
[mailto:rssac-caucus-bounces at icann.org] 代表 Joe Abley
发送时间: 2015年5月20日 0:16
收件人: rssac-caucus at icann.org
主题: [rssac-caucus] possible new work item

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