Hi Andrew! 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? Because non-existence is a cacheable signal and unreachable is not. Joe _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
