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

[Paul Wouters <[e-mail]>]

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