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

[Joe Abley <[e-mail]>]

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 :-)

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

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.

> One interpretation of the draft could be that its purpose is to provide documentation for human consumption. Is this an intended interpretation?

No, not really.

> Or are zone cuts to nowhere also useful information for machines?

Yes.

> 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.

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