Subject: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-7706bis-10: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 12 Mar 2020 00:28:49 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-7706bis-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.)