[dns-operations] [Ext] Re: why does that domain resolve?

Edward Lewis edward.lewis at icann.org
Thu Jun 10 17:41:14 UTC 2021


On 6/10/21, 2:35 AM, "dns-operations on behalf of Petr Špaček" <dns-operations-bounces at dns-oarc.net on behalf of pspacek at isc.org> wrote:

>    Personally, with all the experience we have in 2021, I find the historic 
>    decision to put authoritative NS RRs to the child side to be a poor 
>    choice, to the point of being indefensible.
>
>    As Anthony points out, the parent version of NS has to work anyway. It 
>    forces me to think a better course of action would be ignoring 
>    child-side NS instead of adding complex asynchronous code paths to 
>    validate child NS, which is not technically needed.
>
>    I mean - why waste resources on improving something which is not even 
>    needed?

You need to consider that there are two states - steady and changing.

In a steady state, the two sets are redundant, and redundancy breeds a risk of inconsistency.  So, having both seems suboptimal.

But when the (authorized) zone admin is changing name servers, you need to be able to let the child take the lead.  This allows a zone admin to configure nameservers and bring them up before having to contact the parent admin.  In days of yore, contacting the parent was very manual and delay ridden.  Perhaps there is better automation now, but still the ability to do a local test of any change is important.  Or so I thimk.

On the other hand, relying on the child set of name servers risks falling into a trap where a hijack of the name servers "sticks" because of high TTLs.  (The TTL making records stick in caches even after the clean up.)

DNSSEC signs the child side (apex) servers and not the parent side (cut point) servers.  The parent is authoritative for the zone cut's existence, but the child is authoritative for how they run their portion of the name space, hence what name servers are in use.  This is why the NS is set in the cut point NSEC/NSEC3 but the NS isn't signed.

There's also another angle to consider - the aggressiveness of the querier.  A querier can be aggressive in time - fast answering - and/or it can be aggressive in getting a workable (and/or secure) answer.  Sometimes the child copy is better (authorized admin is changing), sometimes the parent copy is better (the change was unauthorized or malformed).  Relying on the parent is [probably] faster (fewer servers to contact), but pure speed isn't the goal.

No conclusion - just some thoughts.






More information about the dns-operations mailing list