Re: Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice

[David Conrad <[e-mail]>]

Hi,

General comments:

* Given RSSAC-001 has not (to my knowledge) been published, I do not feel this document should be in last call, particularly given it is to move an existing BCP to historic (a bit more on this below).

* The sections on requirements is overly minimalistic. A bit of explanation about those requirements would be useful.

Specific comments:

* Section 1, 2nd paragraph:

   They currently also serve the root-
   servers.net zone and the zone for the .arpa top-level
   domain[ARPAZONE].

The "J" root server does not serve .ARPA.  Perhaps:

"They currently also serve the root-servers.net zone and some root servers serve the .arpa zone."

* Section 1.1, 2nd sentence:

   This document and [RSSAC-001] together functionally replace
   [RFC2870].

Given the IETF does not maintain change control of RSSAC-001, I'm unsure if it is appropriate to reference it as a component of something that is obsoleting 2870.  

* Section 3, title:

      3. Deployment Requirements

I feel this section is talking more about root zone publication requirements. "Deployment Requirements" suggests to me a discussion of the requirements for deploying root servers (e.g., geographical distribution, anycast routing, etc.)

* Section 3, 2nd sentence:

      MUST answer queries from any entity conforming to [RFC1122] with a
      valid IP address.

This requires the root servers to not use any form of response rate limiting, nor impose any sort of sanity checks to where responses will be sent. I believe this is risky and inappropriate in the world of spoofed source address DDoS.

* Section 3, 3rd sentence:

    MUST serve the unique [RFC2826] root zone[ROOTZONE].

As far as I understand, RFC 2826 talks about why a unique root zone is required, it doesn't actually talk about the Internet's root zone.   Perhaps something more along the lines of "MUST, as a result of the technical considerations documented in [RFC2826], serve the Internet's unique root zone[ROOTZONE]." 

This would also probably be place to mention that the unique root zone MUST be published without modification.

* Section 3, 3rd sentence:

      MAY also serve the root-servers.net zone, and the zone for the
      .arpa top-level domain [ARPAZONE],[RFC3172].

Section 3 is talking about requirements, so it isn't clear to me that a "MAY" should be in this section.

* Section 5

I believe it would be appropriate to document that IANA has a responsibility to publish [ROOTZONE], update the root hints, and ensure the root zone trust anchor is published.

Regards,
-drc