I am handling this document as responsible AD, as Warren is a
co-author and so must recuse himself. I’m not sure how I missed the
publication request, but miss it I did, and thanks to Warren for
pinging me.
Thanks for a very well-written and clear document. I have only some
minor editorial comments and a couple of questions, all of which can
be addressed along with any last-call comments that come along. I’ll
request last call right after I send this message.
— Abstract —
data can be kept in the cache beyond the TTL expiry, and also updates
RFC 2181 by interpreting values with the high order bit set as being
positive, rather than 0, and also suggests a cap of 7 days.
The chain of “and also”s feels awkward; I would remove the first one,
so “…TTL expiry, updates RFC 2181…”. (I might remove the second
“also” as well, as “and suggests” is fine without it.) This text is
also in the Introduction, so whatever change is made in the Abstract
should be made in the Introduction too.
— Introduction —
This document proposes that the definition of the TTL be explicitly
expanded to allow for expired data to be used in the exceptional
This isn’t wrong, but for a standards-track document we would usually
say, “This document expands the definition of the TTL to explicitly
allow for…”. It will be published as a Proposed Standard, so I guess
the “proposed” part can just come from there, yes?
— Section 3 —
This is again not [RFC2119]-normative
language, but does convey the natural language connotation that data
In my ongoing effort to disabuse people of the idea that language has
to have BCP 14 key words in order to be normative, I would prefer that
this say, “This wording again does not contain BCP 14 key words,
but…,” because I do believe the quoted text is normative.
Several recursive resolver operators currently use stale data for
answers in some way, including Akamai.
Misplaced modifier:
NEW
Several recursive resolver operators, including Akamai, currently
use stale data for answers in some way.
END
collective operational experience is that it provides significant
benefit with minimal downside.
The antecedent to “it” is unclear (it could refer to Apple MacOS or
the Happy Eyeballs algorithm or mDNSResponder). Better to say, “…is
that using stale data can provide….”
— Section 4 —
If the data is unable to be
authoritatively refreshed when the TTL expires, the record MAY be
used as though it is unexpired.
I wonder if it makes sense to be more explicit here that one isn’t
meant to keep using expired data forever, but is expected to keep
trying to refresh it. So, maybe?:
NEW
If the data is unable to be
authoritatively refreshed when the TTL expires, the record MAY be
used as though it is unexpired until an authoritative refresh is
successful.
END
— Section 5 —
“implementation dependent” needs a hyphen: “implementation-dependent”
— Section 6 —
fact that no other RCODEs which a resolver normally encounters makes
any assertions regarding the name in the question
Number agreement: “make any assertions” (I would also change “which”
to “that”, but I’m picky about using “that” to introduce restrictive
clauses.)
existing cache state. Some authoritative servers operators have said
Either “authoritative server operators” or “authoritative servers’
operators”; I think the former.
their servers are responding with errors like ServFail instead of
giving true authoritative answers. Implementers MAY decide to return
stale answers in this situation.
It might be good for the last paragraph in Section 4, with the
“SHOULD”, to have a forward reference to this explanation.
— Section 10 —
Is another possible new security consideration that bad actors could
DDoS authoritative servers with the explicit intent of having stale
cached information used for longer, perhaps to extend the life of a
cache-poisoning attack or some such?
--
Barry
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
