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/
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
