On 2/8/24, 09:25, "DNSOP on behalf of Philip Homburg" <dnsop-boun...@ietf.org on behalf of pch-dnso...@u-1.phicoh.com> wrote:
>whether fallback to NS/DS is encouraged by the operator of the zone. > >If DELEG is mainly used to signal that a secure transport, such as DoT, DoH, >or DoQ, is available then falling back to NS/DS might be preferred (by the >zone operator) over failure. One of the misconceptions in DNSSEC is that the zone administrator is in control of the situation, dictating the state of signing, the cryptography in use, and so on. DNSSEC is for the benefit of the querier, not the responder. A zone administrator can't force a querier to validate the results, it can't dictate what cryptographic library support the receiver must have. Whatever a zone administrator publishes in a zone on a name server is open to the world, although NSEC3 hashing does help to stem, to some extent, abusive mining of what is published. All choices of how to proceed are made by the recipient. I mention this as a precursor to DELEG design. A zone administrator isn't the beneficiary of secured transports, the receiver is. (The zone administrator already has the data - no need for transporting it.) It is the receiver's choice to attempt to look something up with any receiver-set expectation of privacy, it is the receiver's choice to lower that expectation if it can't be met. The zone administrator is out there in plain sight, anyone can see the data, anyone can see activity. One can't (always) identify the receiver, that's what the privacy-enhancing transports support. A zone administrator may elect to not make data within a zone available via NS/DS delegation, a zone administrator may elect to support only certain transports, akin to only supporting IPv6 but not offering IPv4. The zone administrator does not direct how any fallback happens. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
