[dns-operations] NXDOMAIN vs NOERROR/no answers for non-existant records

[Paul Vixie]

On Thursday, 9 April 2020 23:56:04 UTC Alexander Dupuy wrote:
> Paul Vixie wrote:
> > 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.
> 
> I'd guess this is pretty unlikely, since a minimal online-generated
> NXDOMAIN response would require two NSEC records (you have to prove
> nonexistence of both the queried name and a matching wildcard) and their
> RRSIGs, and these responses are called black lies, not white lies.

i feel like i must be misunderstanding you. there's no lie at all in this 
example:

$(dig @jokulsa.asbyrgi.net all_lies.tisf.net a +dnssec)

the result is 740 octets long, including the DNS cookie, and without using any 
curve-based crypto. there is no truncation nor any likelihood of same. there 
is a proof of nonexistence for the name, and for the matching wildcard. it 
shows rcode 3 (NXDOMAIN).

contrast this against:

$(dig @ns6.cloudflare.com all_lies.cloudflare.com a +dnssec)

CF's "dnssec done right" (their name not mine) contains only one NSEC 
(concerning the qname) and lacks any statement about the nonexistence of the 
wildcard, and expresses rcode 0 (noerror). the crypto is curvy. the response 
is 363 octets in size.

i think CF's decision to send rcode 0 even when the name doesn't exist is a 
false equivalence, and it's expensive for those of us who depend on rcode 3.

any response payload up to 1400 octets will reach every RDNS server whose 
successful operation could affect CF's profits. optimizing for len <= 512 is 
not beneficial to CF but it is costly to the internet security community.

can you start over, perhaps using more words, as to who's lying about what? i 
promise to pay rapt attention. (by the way, when will gmail.com and google.com 
be dnssec-signed, and if never, why never?)

-- 
Paul