[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-ns-revalidation "Delegation Revalidation by DNS Resolvers"

[Peter Thomassen <[e-mail]>]

On 3/18/25 11:54, Shumon Huque wrote:
>      > Follow-up: I guess only updating the NS RRset in the child zone can still cause some queries to go to the faulty operator - you are right about that. So, you have to do it both at the delegation and child zone. Which is what we do.
> 
>     Excellent, that's what I'd thought. I'm just not getting which difference NS revalidation then makes in this situation (as you brought it up as an operational benefit upthread).
[...]
> 
> Re-checking the delegation happens at the smaller TTL of the delegating NS RRset and the Child zone apex NS RRset. So, the child zone can dictate a smaller TTL in accordance with their operational needs for faster reconfiguration, Does that answer your question?

Absolutely, yes!

So this is about when the parent is quick to deploy the update but has a long TTL. Resolvers who query for the first time (or re-check the delegation) will see the update from the parent anyway; however, resolvers who have the NS RRset cached (and are not intending to query the parent) would not have seen the update so quickly if they'd adhere to the parent-side TTL.

I had been under the impression that the issue was parents who are slow to update the delegation. Thanks for this!

Peter

-- 
https://desec.io/