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
