On Wed, 9 Mar 2022, Paul Vixie wrote:
Yeah, this is Paul V's re-worked text regarding revalidation, so I'll
defer to him. Feel free to suggest specific rewording though.
huh. i think the problem is that this paragraph is only one sentence long. my
high school english teachers would have berated me, and others are welcome to
do so now.
If you like these long sentences, I suggest learning German :)
<<A delegation under re-validation is called a "re-validation point". To be
considered "still valid", the ancestor zone whose authority servers offered
the referral response that gave rise to the re-validation point must still
offer a compatible referral response if queried again for a name considered
to be in-bailiwick (a "re-validation query"). To be considered compatible,
the NS RRset of re-validation response must overlap with the previously
cached referral response by at least one name server name, and if a DS RRset
is given, it must overlap with the previously cached referral response by at
least one delegated signer. For avoidance of doubt, this means a change in
referral from signed to unsigned or from unsigned to signed signals a
delegation change for the purposes of this specification, even if the NS
RRset is unchanged.>>
let me know if this isn't an improvement, or if more improvement is needed.
That's much better, thanks.
but to a wholly novel NS RRset or a wholly novel DS RRset
Please use a different word from "novel". Maybe "disjoint NS RRset" ?
ok by me.
Good.
Should the document mention anything for the case of refreshing before
expiration? Eg to keep a hot cache, to requery items that are still
being queried for before their TTL hits? If this feature is supported,
how should it work with the parent/child TTLs?
Pre-fetching? That is worth discussing. Although, it'd be nice if the
details of that mechanism had already been published first. Is anyone
working on reviving/publishing draft-wkumari-dnsop-hammer ? Warren?
pre-fetching is a degenerate case of re-appearance. sometimes an NS RRset
will be transmitted without having been solicited with qtype=NS. these are
not delegations and should not reset the re-validation timers. we might want
to point that out in the specification being discussed in this thread.
(shumon?)
okay.
if a formal specification for "pre-fetching" some day exists and recognizes
that some zones do not answer qtype=NS and that the only way to learn about
delegation points from them is to ask a question that solicits a referral,
and recommends that this be done when "pre-fetching" NS RRsets otherwise due
to expire, then it is that specification's burden to explain how this would
relate to re-validation timers from the (earlier) specification we're
discussing in this thread.
Agree.
Thanks for addressing my items,
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
