If there is, perhaps this will serve as a lesson to them never to tempt the IETF in this way again…
On Tue, Jul 22, 2025, at 5:39 PM, Petr Špaček wrote: > 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] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
