Running a Root Server Local to a Resolver
draft-ietf-dnsop-7706bis-12

Abstract

   Some DNS recursive resolvers have longer-than-desired round-trip
   times to the closest DNS root server; those resolvers may have
   difficulty getting responses from the root servers, such as during a
   network attack.  Some DNS recursive resolver operators want to
   prevent snooping by third parties of requests sent to DNS root
   servers.  Such resolvers can greatly decrease the round-trip time and

Can I suggest to s/Such resolvers/In both cases, resolvers/?

Section 1

   The primary goals of this design are to provide more reliable answers
   for queries to the root zone during network attacks, and to prevent
   queries and responses from being visible on the network.  This design
   will probably have little effect on getting faster responses to stub
   resolver for good queries on TLDs, because the TTL for most TLDs is
   usually long-lived (on the order of a day or two) and is thus usually
   already in the cache of the recursive resolver; the same is true for
   the TTL for negative answers from the root servers.  (Although the
   primary goal of the design is for serving the root zone, the method
   can be used for any zone.)

Are there any considerations of note when using this method for a zone
other than the root zone?

Section 1.1

(I expect the RFC Editor will change things to use a consistent
construction for the last five paragraphs, regarding "this document <X>"
vs. just "<X>".)

Section 2

      only respond to queries from the same host.  One way to assure not
      responding to queries from other hosts is to run an authoritative
      server for the root that responds only on one of the loopback
      addresses (that is, an address in the range 127/8 for IPv4 or ::1

nit(?): in principle there's nothing to stop such a service from
responding on more than one loopback address ... not that I can think of
a reason why one would want to.

Section 3

   There is a risk that a system using a local authoritative server for
   the root zone cannot refresh the contents of the root zone before the
   expire time in the SOA.  A system using a local authoritative server
   for the root zone MUST NOT serve stale data for the root zone.  To
   mitigate the risk that stale data is served, the local root server
   MUST immediately switch to using non-local root servers.

Immediately ... upon what condition?

Section 4

We should probably discuss the consequences for when the SHOULD NOT is
ignored and the glue records in the root zone are changed.

   As stated in Section 1, this design explicitly allows the local copy
   of the root zone information to be available only from resolvers on
   that host.  This has the security property of limiting damage to

nit: "allows [...] to be available only from" or "requires [...] to be
available only from"?  (Or "only allows [...] to be available from", of
course.)

Small editorial comment:
As this document obsoletes RFC7706 (and does not update it), section 1.1 should probably be called "Changes from RFC7706" (and not " Updates from RFC 7706").