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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop