[DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

[Adam Roach via Datatracker <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-dnsop-serve-stale-09: 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-serve-stale/



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


Thanks to everyone who put work into documenting this useful and apparently
well-deployed mechanism. I have a handful of comments on the current document.

---------------------------------------------------------------------------

§3:

>  Several recursive resolver operators, including Akamai, currently use
>  stale data for answers in some way.

This won't age well; and it's not clear why calling out Akamai amongst
the various DNS service providers is warranted. Suggest:

  At the time of this document's publication, several recursive resolver
  operators use stale data for answers in some way

(If the notion of citing Akamai is to indicate the scale of such operators,
I suggest "...operators, including large-scale operators, use stale...")

---------------------------------------------------------------------------

§4:

>  The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is
>  amended to read:
>
>  TTL  a 32-bit unsigned integer number of seconds that specifies the
>     duration that the resource record MAY be cached before the source
>     of the information MUST again be consulted.  Zero values are
>     interpreted to mean that the RR can only be used for the
>     transaction in progress, and should not be cached.  Values SHOULD
>     be capped on the orders of days to weeks, with a recommended cap
>     of 604,800 seconds (seven days).  If the data is unable to be
>     authoritatively refreshed when the TTL expires, the record MAY be
>     used as though it is unexpired.  See the Section 5 and Section 6
>     sections for details.


The addition of what I must presume is intended to be RFC 2119 language to a
document that doesn't cite RFC 2119 seems questionable.  I would suggest
either explicitly adding RFC 2119 boilerplate to RFC 1035 as part of this
update, or using plain English language to convey the same concepts as are
intended.

Nit: "See the Section 5 and Section 6 sections for details" is a very awkward
way to phrase the closing sentence.

More substantively: Sections 5 and 6 of RFC 1035 are "MASTER FILES" and "NAME
SERVER IMPLEMENTATION" respectively. Is this final sentence intended to refer to
those two sections? Or is it pointing to "Example Method" and "Implementation
Considerations" of this document? If the latter, please specifically cite this
document (e.g., "See Section 5 and Section 6 of [RFCXXXX] for details.")

---------------------------------------------------------------------------

§4:

>  therefor leave any previous state intact.  See Section 6 for a

Nit: "therefore"

---------------------------------------------------------------------------

§5:

>  When a request is received by a recursive resolver, it should start
>  the client response timer.

The passive tense in this sentence makes "it" linguistically ambiguous.
Suggest: "When the recursive resolver receives a request, it should start..."

---------------------------------------------------------------------------

§10:

>  A proposed mitigation is that certificate authorities
>  should fully look up each name starting at the DNS root for every
>  name lookup.  Alternatively, CAs should use a resolver that is not
>  serving stale data.

This seems like a perfectly good solution, although I wonder how many CAs are
likely to read this document. If I were the type to engage in wagering, I'd
put all of my money on "zero." I'm not sure specific action is called for
prior to publication of this document as an RFC, but it seems that additional
publicity of this issue and the way that serve-stale interacts with it --
e.g., to CAB Forum and its members -- is warranted.