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(_at_)elandsys(_dot_)com> 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