Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-02.txt

[Paul Vixie <[e-mail]>]

see inline.

Shumon Huque wrote on 2022-03-08 21:12:
> On Tue, Mar 8, 2022 at 1:04 PM Paul Wouters 
> <paul.wouters=[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     On Mon, 7 Mar 2022, [e-mail]
>     <mailto:[e-mail]> 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