[dns-operations] At least 3 CloudFlare DNS-hosted domains with oddball TLSA lookup ServFail

[Viktor Dukhovni]

On Sun, Apr 19, 2020 at 01:52:35PM +0200, Florian Weimer wrote:
> * Vladimír Čunát:
> 
> > (I don't react to the SERVFAIL from CloudFlare auth.)
> >
> > On 4/19/20 8:55 AM, Viktor Dukhovni wrote:
> >> the NSEC RR promises TLSA records, among a rather oddball mix of
> >> other rrtypes
> >
> > I believe that's normal for CloudFlare authoritatives, and so far I've
> > noticed no real problems from that, apart from effects like less
> > efficient caching.  Description:
> > https://blog.cloudflare.com/black-lies/#dnsshotgun

It can't be "normal", because the auth servers ServFail when I request
the promised TLSA RRs.

> For me, queries to alla.ns.cloudflare.com for
> _25._tcp.mx01.mx-hosting.ch/IN/TLSA time out (even over TCP).  That
> breaks denial of existence and thus DANE.  There is no obvious
> client-side workaround because the NSEC RRset says that the TLSA RRset
> exists.

As Florian points out, whether the response is ServFail, or a timeout
this breaks email delivery via the affected MX host.  Out of hundreds of
thousands (perhaps over a million) signed domains DNS-hosted by
CloudFlare, I've only found three cases of this problem, so it sure
looks an anomaly, rather than the norm.

> Could this work if the authoriative server returned an RRSIG signature
> of an empty TLSA RRset?

An interesting hypothetical, my take is "no", that's what NSEC is for.

    signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where

seems to suggest that there's at least an RR(1), but indeed the language
is not 100% clear on whether signatures of empty RRsets are valid.

-- 
    Viktor.