see inline.
Shumon Huque wrote on 2022-03-08 21:12:
On Tue, Mar 8, 2022 at 1:04 PM Paul Wouters
<[email protected]
<mailto:[email protected]>> wrote:
On Mon, 7 Mar 2022, [email protected]
<mailto:[email protected]> wrote:
> Subject: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-02.txt
...
A delegation under re-validation is called a "re-validation point"
and is "still valid" if its parent zone's servers still respond to
an in-zone question with a referral to the re-validation point, and if
that referral overlaps with the previously cached referral by at
least one name server name, and the DS RRset (if seen) overlaps the
previously cached DS RRset (if also seen) by at least one delegated
signer.
This paragraph, from an implemeter's point of view, is super dense. It
might be worth splitting this one sentence into multiple ones.
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. let's try breaking it up a bit.
<<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.
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.
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?)
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.
my hope is that a "pre-fetching" specification would not recommend
soliciting NS RRsets via referrals, and would instead exclude NS RRsets
from pre-fetching, with a reference to the specification we're
discussing in this thread and a recommendation that re-validation and
not pre-fetching be used when the near-expiry cached RRset is rrtype=NS.
--
P Vixie
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
