Re: [DNSOP] draft of RFC 2870-bis for consideration
Nits and notes: Abstract: O: The DNS is considered a crucial part of that technical infrastrcuture. P: The DNS is considered a crucial part of that technical infrastructure. C: s/infrastrcuture/infrastructure/ -- typo. Background: O: ...servers to enable robust dand resilient… P: ...servers to enable robust and resilient… C: s/dand/and/ -- typo. 1.4: O: ...temporary simulatneous loss of many… P: ...temporary simultaneous loss of many… C: s/simulatneous/simultaneous/ -- typo. 3.2.1: O: ...for TSIG and DNSSEC syncronization… P: ...for TSIG and DNSSEC synchronization… C: s/syncronization/synchronization/ -- typo. 3.2.6: O: Servers must log in UTC to facilitate log comparison. C: Seems a little strong -- If I want to log in fortnights since lunar eclipse, that's my business -- as long as I'm willing to convert the log to UTC before handing it to be analyzed. 3.2.8: O: The server should be protected from attacks based on source routing. The server must not soley rely on address- or name-based authentication. C: Seems like it should have more text. Not entirely sure what is being said here. also: s/soley/solely/ -- typo. 3.3.6: O: ...based on the currnet update cycle… P: ...based on the current update cycle… C: s/currnet/current/ -- typo. 3.3.10: O: These monitoring processes could be automated. P: These monitoring processes should be automated. 4.2: C: See draft-mcpherson-unique-origin-as-00 (expired). Neither supporting nor opposing the draft, just mentioning it. 5.1: O: ... a scheduled maintaince window… P: ... a scheduled maintenance window… C: s/maintaince/maintenance/ --typo. W On Feb 1, 2012, at 7:11 AM, bmann...@vacation.karoshi.com 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft of RFC 2870-bis for consideration
will fold them in, thanks. /bill On Sun, Feb 05, 2012 at 11:34:06AM -0500, Warren Kumari wrote: Nits and notes: Abstract: O: The DNS is considered a crucial part of that technical infrastrcuture. P: The DNS is considered a crucial part of that technical infrastructure. C: s/infrastrcuture/infrastructure/ -- typo. Background: O: ...servers to enable robust dand resilientb P: ...servers to enable robust and resilientb C: s/dand/and/ -- typo. 1.4: O: ...temporary simulatneous loss of manyb P: ...temporary simultaneous loss of manyb C: s/simulatneous/simultaneous/ -- typo. 3.2.1: O: ...for TSIG and DNSSEC syncronizationb P: ...for TSIG and DNSSEC synchronizationb C: s/syncronization/synchronization/ -- typo. 3.2.6: O: Servers must log in UTC to facilitate log comparison. C: Seems a little strong -- If I want to log in fortnights since lunar eclipse, that's my business -- as long as I'm willing to convert the log to UTC before handing it to be analyzed. 3.2.8: O: The server should be protected from attacks based on source routing. The server must not soley rely on address- or name-based authentication. C: Seems like it should have more text. Not entirely sure what is being said here. also: s/soley/solely/ -- typo. 3.3.6: O: ...based on the currnet update cycleb P: ...based on the current update cycleb C: s/currnet/current/ -- typo. 3.3.10: O: These monitoring processes could be automated. P: These monitoring processes should be automated. 4.2: C: See draft-mcpherson-unique-origin-as-00 (expired). Neither supporting nor opposing the draft, just mentioning it. 5.1: O: ... a scheduled maintaince windowb P: ... a scheduled maintenance windowb C: s/maintaince/maintenance/ --typo. W On Feb 1, 2012, at 7:11 AM, bmann...@vacation.karoshi.com 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft of RFC 2870-bis for consideration
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
Re: [DNSOP] draft of RFC 2870-bis for consideration
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
Re: [DNSOP] draft of RFC 2870-bis for consideration
thanks. will fold in your comments. /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft of RFC 2870-bis for consideration
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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
