[DNSOP] Re: on the more general problem of delegating to other namespaces in the DNS

[Andrew McConachie <[e-mail]>]

On 23 Jun 2025, at 12:21, Joe Abley wrote:

> Hi Andrew,
>
> This seems like a clarifying question rather than the kind of 
> rehashing of an old question that our esteemed chairs would prefer to 
> be put on hold, and hence seems very reasonable to me. If I have 
> misunderstood the chairs' preference here I am sure one of them will 
> tell us :-)
>
Thanks for the detailed response!

> On 23 Jun 2025, at 11:34, Andrew McConachie <[e-mail]> wrote:
>
>> I’ve read through the draft as well as the messages on list, but I 
>> still don’t understand the use case for this draft. Why is creating 
>> a delegation to nowhere better than doing nothing?
>
> In practice, people have been using internal namespaces, with and 
> without DNSSEC validation on mobile devices, for long enough that I am 
> not convinced there is a widespread problem to solve. This, I think, 
> is John Levine's pragmatic perspective, which the chairs would like us 
> to stop going on and on an about regardless of whether we agree with 
> John or not.
>
> However, the point of the draft (if I'm right and it has one) is that 
> having a signed proof of non-existence for a (QNAME, QCLASS, QTYPE) 
> from one set of nameservers and answers for the same (QNAME, QCLASS, 
> QTYPE) from a different set of nameservers does introduce ambiguity. I 
> think we could probably all come up with scenarios where believing the 
> non-existence is the right thing to do (e.g. protection from bogus 
> responses), and also other scenarios where believing the responses is 
> the right thing to do (e.g. my local networks, my local rules).
>
> The difference in behaviour between (a) do nothing and (b) zone cut to 
> nowhere is that (a) necessarily leaves the door open to ambiguous 
> responses and (b) does not.
>
> The way that (b) avoids ambiguity is that it deliberately sabotages 
> resolution in the case where there is no definitive answer to give, 
> e.g. in the case where the root servers cannot say whether a name 
> under INTERNAL should exist given the circumstances of a particular 
> device that is asking. This means the device cannot cache an answer 
> that would cause ambiguity because no such answer can be found. You 
> either can't get an answer at all, or you can get an answer that has 
> local significance. As a bonus, this mechanism allows answers of local 
> significance to be signed in a way that can be validated

But a device can also not cache an answer if the name is not present in 
the parent zone. Adding a zone cut to nowhere doesn’t stop a device 
from caching some RRSet. It can stop a device from caching an NSEC RR or 
NXDOMAIN rcode. But the device still doesn’t know which side of the 
DNS-split horizon it currently sits on. I assume most modern devices 
flush their DNS cache at DHCP/SLAAC renewal, so maybe this is a moot 
point.

Regarding the DNSSEC trust chain, it’s broken with both a zone cut to 
nowhere and a non-existent name. I guess the point this draft makes is 
that a signed lame delegation is better than a signed proof of 
non-existence. Either way the private resolver or private authoritative 
will have to ‘fake’ some DNSSEC data, because there can never be a 
‘real’ signed DS RR in the parent zone.

>
> The trade-off may be that there is some operational consequence of the 
> lame delegation to a server that does not exist, e.g. problematic 
> levels of unwanted traffic sent to root servers or query storms or 
> other worrisome effects from resolvers that are dreadfully surprised 
> by the empty hostname. This is the science that Wes is currently 
> stirring in his cauldron.

More testing is always good!

<snip>

>> If so, how SHOULD a resolver on the private side of split-horizon dns 
>> behave when it encounters a zone cut to nowhere?
>
> A resolver that provides responses from a private namespace will not 
> encounter a zone cut to nowhere for that namespace. Such a resolver 
> will have access to DNS data that it can use to return responses, e.g. 
> by being configured to respond authoritatively to zones corresponding 
> to the internal-use namespace, or by having explicit "forwarder" 
> configuration so they know which authoritative nameservers to consult.

Regardless of whether a zone cut to nowehere exists for 
duckling.example.org the behavior of the authoritative server for 
duckling.example.org doesn’t change. There’s no difference between 
the two cases. Please correct me if I’m wrong.

I’m still left with the question of: Why is a (signed/unsigned) 
lame-delegation better than (signed/unsigned) non-existence?

>
> A resolver that is not configured like that or which encounters a zone 
> cut to nowhere for some namespace that it doesn't care about will 
> behave the same as it would when encountering a referral response to 
> servers that can't be resolved. It will fail, hopefully in a 
> predictable way.
>
>
> Joe
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]