On Mon, Jul 31, 2023 at 11:58 AM Edward Lewis <edward.le...@icann.org<mailto:edward.le...@icann.org>> wrote: >You've probably stumbled across Cloudflare's differential behavior for DO=0 vs >DO=1 queries. With non-DNSSEC queries it provides a vanilla, unsigned >NXDOMAIN response. With DNSSEC enabled queries, it provides the >Compact Answer NODATA response.
Stumbled isn’t the right word - I purposely went looking for it, found it as had I expected. This is what was “feared” in the section in “Protocol Modifications for the DNS Security Extensions” titled “Including NSEC RRs in a Zone“ [a.k.a. RFC 4035, 2.3] - the divergence of the unsecured and secured view of a zone. Backwards compatibility was one of the chief concerns in designing DNSSEC as it was expected that it would take it a very long time to achieve full deployment - and it was anticipated that “islands of security” would emerge before top-down. (I don’t think there are many “islands of security”, especially the way the DNS service economy has emerged this century.) >Your 1st query probably was DO=0. For your 2nd query, I assume the recursive >server that you used sent DO=1 queries upstream by default. Yep. Well, not “by default” - I diddled the DiG run time parameters to make sure I did that… >Yes, this is kind of confusing, and I'm not particularly a fan of this >differential >behavior. “Confusing” situations ought to be avoided. Confusing is a problem in situations when “mean time to repair” matters. My general concern is that although things may “work” in practice today and there’s a desire for expediency, but the way in which this pleases or displeases operations will be a large factor in whether deployment is achieved. As has been the case in other finer points of the extension definitions, the rule against names only having an NSEC (and RRSIG) emerged in the context of developing the signing process. At the time, the prevailing winds would have justified preparing an NSEC resource record set for each name in the zone, including empty non-terminals and possible even those that did not exist (no data and no descendants). I can’t think of a negative impact on a validator verifying that a name had only an NSEC record, but that wasn’t the concern at the time. What wasn’t done was disallowing queries for NSEC, by the time NSEC3 was derived, this was “fixed” (meaning, explicitly barred). Buried in here is the notion that we want to tailor the response to match the query. The only time this is done in base DNS is in answer synthesis (wildcards) and the only field modified there is the owner field. DNSSEC accommodates this (and any decrement to the TTL). We don’t have any precedent in the protocol for modifying the RDATA field based on the query, and DNSSEC was not built anticipating that.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
