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