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

[Petr Špaček <[e-mail]>]

On 24. 06. 25 13:39, Joe Abley wrote:
> On 24 Jun 2025, at 12:20, Andrew McConachie <[e-mail]> wrote:
> 
>> But a device can also not cache an answer if the name is not present in the parent zone.
> 
> Ah, so this is not actually true. A device can cache a negative response from the parent zone, see RFC 2308.
> 
>> Adding a zone cut to nowhere doesn’t stop a device from caching some RRSet.
> 
> It stops a device from caching the non-existence of a name, because a referral response is a signal that the name exists (unlike a NODATA response or an NXDOMAIN response, with or without DNSSEC).
> 
>> Regarding the DNSSEC trust chain, it’s broken with both a zone cut to nowhere and a non-existent name.
> 
> In some cases, the point is to break the chain of trust. An insecure delegation to nowhere is thought by some to be useful in the case of .INTERNAL, for example, so that there is no signed proof of non-existence of the INTERNAL domain possible from a root server that might contradict the existence of the INTERNAL domain in a private namespace.
> 
> In other cases, the opportunity is to preserve a chain of trust. A secure delegation to nowhere for INTERNAL.COMPANY.EXAMPLE zone might be installed in the global-scope COMPANY.EXAMPLE zone; the DS RRSet installed in public might match the KSKs used to sign the DNSKEY RRSet at the INTERNAL.COMPANY.EXAMPLE zone which is visible in a private network. This might allow devices to be able to get secure responses from internal-network nameservers without needing keys to be distributed through mobile device management systems.
> 
>> 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.
> 
> See above for a real-world example of when such a secure delegation to nowhere might be useful.
> 
>> I’m still left with the question of: Why is a (signed/unsigned) lame-delegation better than (signed/unsigned) non-existence?


Disclaimer:
I very much support this draft. It makes sense to me conceptually and it 
also solves several operational issues related to delegation vs. DS 
RRset non-existence & private namespaces.


Having said that, I violently disagree with this:

> Because non-existence is a cacheable signal and unreachable is not.
Sorry but this statement is as incorrect as it gets.

The draft section '4. Interpreting a Referral to Nowhere' explicitly 
specifies this is NOT the case and that all normal caching rules apply. 
Here's walk through an example to explain.


Assume these RRsets are in the root zone:
internal. 172800 NS .
. 86400 SOA ... 86400

Let's explore RD=1 query for 'example.internal. A':
- The resolver will get the referral 'internal. NS .'
- Address records will be missing in the referral so it will try to 
fetch '. A' + '. AAAA'
- '. A/AAAA' do not exist and this information will get cached for 
duration specified by '. SOA', see RFC 2308 section 3 and 4.
- This will ultimately cause resolution failure and SERVFAIL will be 
sent back to the client.
- This SERVFAIL will most likely be further cached by RFC 2308 section 
7, at least for 'example.internal. A' tuple. (BAD cache, implementation 
dependent.)

Now imagine a client re-queries again for 'example.internal. A':
- Resolver will check the BAD cache. If it still has previous failure 
cached immediate SERVFAIL ensues.
- If BAD cache expired, resolver will try to resolve the stuff again and 
number of queries sent out to root will depend on state of 'internal. 
NS' and '. A/AAAA' in cache.


For the fun of it, imagine client asked for 'somethingelse.internal. A':
Number of queries going out will depend on state of cache again, except 
that BAD cache might not be applicable if it is keyed on exact 
(QNAME,QTYPE) - depends on implementation.


So all in all, the primary difference will be RCODE SERVFAIL vs. 
NXDOMAIN in response from resolver. Consequently RFC 8198 will not be 
effective for SERVFAILs and a validating resolver has to do marginally 
more work to arrive at the SERVFAIL (consulting cache several times to 
find out there's nobody to contact), but other than that, the end effect 
_of caching_ is effectively the same, including TTLs involved.



This draft potentially could specifying special handling for 'NS .' so a 
nowhere-aware resolver could do less work for these cases and perhaps 
modify it's caching strategy somehow (like, skip BAD cache, shorter TTLs 
and what not). But hey, perhaps there's some insane private instance of 
DNS where '. AAAA' exists!

-- 
Petr Špaček
Internet Systems Consortium