Hi SM, Some reaction to your comments below, plus a comment of my own. I'll note that I am not a root server operator, although in the past I have played one on TV. My comments on your comments are provided merely as additional thoughts from an innocent bystander. On 22 May 2014, at 1:23, S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote: > In Section 1: > > "The operational requirements are defined in [RSSAC-001]." > > There isn't any document about Service Expectations at > http://www.icann.org/en/groups/rssac I understand that RSSAC have made recent progress on that document, and that it will appear soon. I would presume that the RFC Editor would hold final publication of this document, once approved, until that reference showed up, as is the case for references to IETF documents. I don't know whether that's a good presumption though. I just thought I'd mention it as a plausible workflow. > According to a message posted a few months ago c.root-servers.net is not reachable on 2001:500:2::c from one network. Section 3 of the draft mentions that the root name service must answer queries from any entity with a valid IP address. At any time many parts of the Internet are unreachable from other parts of the Internet, for many reasons unrelated to specifications (national issues, cable breaks, failures in particular networks, peering disputes, etc.) I'll note that the document describes requirements for the *service*, not for any particular component of the service. So I think this concern is orthogonal to the purpose and contents of this document. > I'll note that there will no longer be an IETF document with the following requirement: > > "The root zone MUST be signed by the Internet Assigned Numbers > Authority (IANA) in accordance with DNSSEC" I actually think that it makes sense to separate the requirements for the root name *service* from the contents of the root zone that is being served. The document requires the service to support DNSSEC (which I think is right and proper), and has nothing to say about the contents of the root zone (which again, I think is right and proper). I have one comment of my own. Section 3 specifies that: > 3. Deployment Requirements > > The root name service: > > MUST answer queries from any entity conforming to [RFC1122] with a > valid IP address. The document does not discuss what "valid" means in this context. In a protocol sense, "valid" presumably means "well-formed", which means that any 32-bit/128-bit integer will do. The address 10.4.5.6 is a valid IP address in a protocol sense, although use of that address is constrained operationally by RFC 1918. It would be reasonable not to send a response to a query from an address that is known to be unreachable from the point of view of the root server. Inbound queries with source addresses for which there is no corresponding return route, similarly, cannot be usefully replied to. Individual root servers with (e.g.) unicast RPF configured upstream will not receive those queries. In this category are addresses that have not been allocated by an RIR or are not announced on the Internet for some other reason (perhaps they are used in disconnected networks which are leaking). Individual root servers have in the past mitigated attack traffic (e.g. reflection attacks) using techniques such as Response Rate Limiting. There is good reason to believe that such techniques do a good job at allowing legitimate queries to be answered whilst preventing responses that might otherwise enable (e.g.) a reflection attack. Taken at face value, this MUST requires individual root server operators to do things that, operationally, are undesirable. I suggest some qualification, e.g. of the form "the root name service MAY refuse to answer particular queries to mitigate operational events that might otherwise threaten its stability and availability". Joe