On 24. 06. 25 13:39, Joe Abley wrote:
On 24 Jun 2025, at 12:20, Andrew McConachie <[email protected]> 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
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
