[dns-operations] At least 3 CloudFlare DNS-hosted domains with oddball TLSA lookup ServFail
ietf-dane at dukhovni.org
Sun Apr 19 16:49:36 UTC 2020
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
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.
More information about the dns-operations