Subject: [DNSOP] draft of RFC 2870-bis for consideration

From: [email-masked]
Date: Wed, 1 Feb 2012 12:11:28 +0000

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

---

From: John Dickinson <[email-masked]>
Date: Wed, 1 Feb 2012 17:07:45 +0000

> It is currently posted as:
…

> Your comments would be appreciated.

Hi,

The document is good and useful, here are a few nits and comments.

Abstract:
Remove the word "safe" - what does it mean?
Reword and correct spelling in last two sentences to say "The DNS is considered a crucial part of the Internet infrastructure. The root zone and its authoritative name servers are a key part of that DNS infrastructure."

1. Background:
Inconsistent use of 1 or 2 spaces after a full stop.

Sentence 1: As before, remove the word "safe". Also s/domain/zone/

Sentence 3: mentions "... name service known by its letter, ...". Remove the words "known by its letter," and add a sentence before this one saying "Each of the 13 authoritative root name servers are identified by a letter A - M.".

1.5.
Sentence 2: s/transit are be considered/transit are considered/

Penultimate paragraph: This repeats text that is already in the beginning of this section.

2.  The Servers Themselves
2.2 modify to read "... the IETF standards relating to authoritative DNS, ..."

2.3 modify to read "... able to handle a load of DNS queries which ..." or even "... able to handle a packet load which ..."

2.6 last sentence:
I don't really get this sentence - isn't it covered by just saying something like "Send the response to the source address of the query"?

3.2.1:
Sentence 1:
Network time protocol should not be acting as a server on root servers (as stated in 3.2.5).
Routing daemons may be needed on the name server to allow 1.6 and 4.4.

Sentence 2:
remove 1 space from between the words "likely" and "there".
I think the last sentence is too restrictive (As long as secure authentication and encryption are available).

3.3.5 is hard to parse. Also sections 3.3.7 and 3.3.8, Can these not refer to the root zone DPS and other similar documents?

I note that there is no mention of the root DPS anywhere in this draft.

3.3.9 Should this start "Each root operator ..."

4.1 Last sentence is wrong or I don't understand it - "Root server nodes be numbered (v4 and v6) using addresses ..." and I am not sure of the correct wording.

4.2 I am not an anycast expert but should this read "Each of a root server's anycast instances MUST be sourced ..."?

HTH
John

---
[email-masked]

http://sinodun.com

Sinodun Internet Technologies Ltd.
Stables 4, Suite 11,
Howbery Park,
Wallingford,
Oxfordshire,
OX10 8BA,
U.K.

+44 (0)1491 834957

---

From: [email-masked]
Date: Wed, 1 Feb 2012 17:09:32 +0000

thanks.  will fold in your comments.

/bill

---

From: Warren Kumari <[email-masked]>
Date: Sun, 5 Feb 2012 11:34:06 -0500

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, [email-masked] wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 

--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.

---

From: [email-masked]
Date: Sun, 5 Feb 2012 22:02:33 +0000

will fold them in, thanks.

/bill

On Sun, Feb 05, 2012 at 11:34:06AM -0500, Warren Kumari wrote:
> 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&
> O: ...for TSIG and DNSSEC syncronizationb&
> P: ...for TSIG and DNSSEC synchronizationb&
> O: ...based on the currnet update cycleb&
> P: ...based on the current update cycleb&
> O: ... a scheduled maintaince windowb&
> P: ... a scheduled maintenance windowb&

---

From: David Conrad <[email-masked]>
Date: Sun, 5 Feb 2012 19:40:49 -0800

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/

---

From: [email-masked]
Date: Mon, 6 Feb 2012 03:42:43 +0000

thanks!  will fold in accordingly.

/bill