thanks! will fold in accordingly. /bill
On Sun, Feb 05, 2012 at 07:40:49PM -0800, David Conrad wrote: > Bill, > > Comments/nits/etc. > > Regards, > -drc > -------- > Last sentence of Abstract: > > "... zones may also find it useful." > > Might suggest "... zones may also find this document useful." > --- > 1. Background, second sentence: > > "The Internet Assigned Numbers Authority (IANA) publishes ..." > > Should be: > > "The Internet Assigned Numbers Authority functions operator (IANA) publishes > ..." > --- > 1. Background, next sentence: > > "... refer to the many ways a root operator provisions to provide root name > service known by its letter, ..." > > Since the naming convention of the root servers isn't introduced to this > point (or discussed later or even germane to the discussion), I'd suggest > dropping "known by its letter," > --- > 1. Background, last sentence of first paragraph: > > Typo "dand". > --- > The sub-points of section 1 aren't really introduced, they just sort of show > up. Perhaps before 1.1, putting something like "At a high level, the root > servers operate under the following general characteristics:" or somesuch. > --- > 1.2 "For legacy reasons, some of the root servers have also served other > important zones, In the future, the data served by root servers may change > after careful review by RSSAC and ICANN." > > The second comma should probably be a period. The use of a past-tense verb > suggests that some of the root servers are not now serving other important > zones. Since those root servers still serve those zones, it would be > clearer to state: > > "For legacy reasons, some of the root servers serve other important zones. In > the future ..." > --- > 1.4 "The domain name system has proven to be sufficiently robust that the > temporary simulatneous loss of many of the root server instances does not > significantly affect secure and stable operation of the Internet. [citeation]" > > I'm not sure the ambiguous term "many" is warranted, particularly without a > citation. Perhaps "loss of a number of" and "has not ... affected" instead > of "does not ... affect" since that suggests loss occurs with some frequency. > Also typo: "simultaneous". > --- > 1.5 "Authentication, validation, and security of these data and the > communications channels they transit are be considered possible attack > vectors." > > "are to be" or "should be" and I think you want the term "vulnerabilities", > not "attack vectors". > --- > 1.5 "... equal-cost multipath routing and Anycast routing. (Anycast is > discussed further in Section 4.)" > > Probably should provide a citation to the documents that define anycast here, > e.g., RFC 3258 (as opposed to later). > --- > "For simplicity, this document uses the term "server" to refer to however > many hosts a root operator provisions to provide root name service at a > single address per address family." > > Duplicative of wording in the first paragraph of this section. > --- > "2. The Servers Themselves" > > Given there is no mechanism for enforcement, these aren't "requirements". > They are better termed "suggestions" or perhaps couched in terms of "best > current practices". > --- > 2.1 Not phrased as an imperative. It also isn't clear as to whether this is > discussing the root server _system_ or an individual root server operator's > implementation of their part of the system. Assuming the former, perhaps: > > "In order to improve overall robustness, the root server system SHOULD > utilize heterogeneous hardware, operating systems, network topology, and name > serving software across the root name servers." > --- > 2.2 Not phrased as an imperative. Perhaps: > > "While there are no accepted, formal test suites for standards compliance, > the maintainers of software used on root servers SHOULD take all reasonable > actions to ensure their DNS server software correctly implements the IETF > standards for authoritative DNS, including RFC1035[2], RFC2181[3], > RFC4035[14] and others that conform to the IETF's then-current documented > expectations." > --- > 2.3 "... each server must be able ..." > > s/must/SHOULD/ > --- > 2.4 "Connectivity to the Internet should be as diverse as possible." > > Expansion/clarification of this sentence would probably be helpful. > Diversity in terms of what? > --- > 2.5 s/must/SHOULD/ > > Also, I might quibble about overgeneralizing. There are authoritative name > servers that cache responses in order to improve performance. As the root > zone grows, this may become more important. It might be prudent to clarify > what sort of caching this suggestion is recommending against. > --- > 2.6 s/must/SHOULD/ > > Also, clarification of "valid IP address" is probably warranted, e.g., > "allocated IP address". I think it appropriate for root servers to NOT > respond to queries from (e.g.) IPv4 10/8 or anything in IPv6 outside of the > current FP. > --- > 2.8 s/must/SHOULD/ > --- > 3.1 s/will/SHOULD/ > --- > 3.1.1 s/must/SHOULD/ > --- > 3.1.2 s/must/SHOULD/ > --- > 3.1.3 s/must/SHOULD/ > --- > 3.1.4 s/must/SHOULD/ > --- > 3.2.1 "routing daemons" > > My understanding is that this would preclude some (many? all?) root server > instances from withdrawing their internal /32 (/128?) route should their DNS > server be observed to crash. > > s/must/SHOULD/ > > "and locations from which remote login is allowed must be protected and > hardened" > > s/must/SHOULD/ > > Also, might be worthwhile documenting the presumption that remote login from > non-protected/hardened locations would be assumed to go through a bastion > host of some kind (if that is the presumption). > --- > 3.2.2 s/must/SHOULD/ > --- > 3.2.4 "The broadcast domain(s) in which a root server node is located should > be separately firewalled or packet filtered to prohibit network access to any > port other than those needed for name service." > > This would seem to preclude people ssh'ing into a root server instance. > Perhaps "... for name service and administration of the name server." > --- > 3.2.5 Might also suggest servers could use external (e.g., GPS-based) clocks. > --- > 3.2.8 s/must/SHOULD/ > --- > 3.3 "Protocol authentication and security are required to ..." > > As before, since there is no mechanism for enforcement, I'd recommend > rephrasing this to "Protocol authentication and security should be used to > ..." > --- > 3.3.1 is not a requirement for root server operators (and besides, as > written, this is wrong -- the root zone is signed and maintained by the U.S. > Dept. of Commerce contractor, currently Verisign, not the IANA functions > operator). > --- > 3.3.2 s/must/SHOULD/ > --- > 3.3.3 s/must/SHOULD/ > --- > 3.3.7 12 hours seems a bit long for an 'emergency update'. > --- > 3.3.8 s/must/SHOULD/ > --- > 3.3.10 s/must/SHOULD/ > --- > 4.1 To give the dead horse another whack, given the challenges associated > with renumbering root name servers (specifically the long half-life of the > old addresses and, as a result, the inability to reuse those address) and the > requirement inherent in the DNS protocol to avoid the chicken-or-egg problem > in resolving root server addresses, I believe we should treat root server IP > addresses as "golden addresses" a la RFC 3068 and not the "property" of the > root server operators. > --- > 4.3 s/must/SHOULD/ > --- > 4.6 The last sentence probably shouldn't be a question. > --- > 5.4 is missing > --- > 5.5 s/must/SHOULD/ > > > On Feb 1, 2012, at 4:11 AM, [email protected] wrote: > > > > The Root Server System Advisory Committee of ICANN has been working on a > > revision to RFC 2870. > > It is currently posted as: > > > > ------------ > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : Root Name Server Operational Requirements > > Author(s) : Root Server System Advisory Committee > > Filename : draft-rssac-dnsop-rfc2870bis-03.txt > > Pages : 9 > > Date : 2012-01-31 > > > > As the Internet has become critical to the world's social and economic > > infrastructure, attention has focused on the correct, safe, reliable, and > > secure operation of the Internet infrastructure itself. The DNS is > > considered > > a crucial part of that technical infrastrcuture. The root domain and its > > authoritative name servers are a part of that technical infrastructure. > > > > The primary focus of this document is to provide guidelines for secure, > > stable, > > and resilient authoritative name service for the root zone. Additionally > > it will > > look into some specifics for the operation of the name servers. Other > > operators > > of authoritative name servers such as those for generic top-level domains > > (gTLDs), > > country code top-level domains (ccTLDs) and other zones may also find it > > useful. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-rssac-dnsop-rfc2870bis-03.txt > > ------------ > > > > Your comments would be appreciated. > > > > /bill > > _______________________________________________ > > DNSOP mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
