On Monday, 6 April 2020 16:19:44 UTC Dave Lawrence wrote: > Matthew Richardson writes: > > However, is this going to cause any practical problems? > > Even outside DNSSEC, where it absolutely would be a problem, there are > some context for specialty applications where the difference between > the two types of negative answers is meaningful. The examples I can > think of off the top of my head are proprietary, but the general idea > should hold: if two things have semantically different meanings, > people somewhere are making use of the distinction.
when i first read "dnssec done right", i thought as you describe. hereis: https://blog.cloudflare.com/dnssec-done-right/ no mystery: i still think as you describe. the text in question is this: > DNSSEC Done Right > January 29, 2015 12:10 PM > Ólafur Guðmundsson > ... > Second, we do negative answers in a special way. Negative answers in DNSSEC > can get large. For zones signed with NSEC, it’s not uncommon to have SOA + > RRSIG(SOA) + 2 NSEC records + 2 RRSIG(NSEC) records in the negative > answers. Even for the weakest RSA keys allowed, this results in an answer > that is at least 635 bytes. NSEC3 signed answers require, in most cases, 3 > NSEC3 and 3 RRSIG (NSEC3) records to deny the existence of the item asked > for—that’s at least 1000 bytes. So we selected NSEC as our negative answer > and use ECC keys. But the biggest saving comes from not having to prove > that the covering wildcard exists at all, which is the role of the second > NSEC record. We return an answer that says, “sure, the name exists, but the > type you asked for does not”. This allows us to return only one NSEC record > in negative answers! i hope CF will differentiate NODATA from NXDOMAIN in their signed DNSSEC responses, because the difference is absolutely vital to anyone who uses DNS analytics as a defense vector. cc'ing the author of that blog post here, in case this thread wasn't visible. -- Paul _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
