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

[Viktor Dukhovni]

On Wed, May 27, 2020 at 05:34:13PM +0100, Christian Elmerot wrote:

> >      @alla.ns.cloudflare.com.[173.245.58.62]
> >      ; <<>> DiG 9.16.2 <<>> +noidnout +nosearch +dnssec +noall +cmd +comment +qu +ans +auth +nocl +nottl +nosplit +norecur -t tlsa _25._tcp.mx01.mx-hosting.ch @173.245.58.62
> >      ;; connection timed out; no servers could be reached
> >
> >      @guss.ns.cloudflare.com.[173.245.59.172]
> >      ; <<>> DiG 9.16.2 <<>> +noidnout +nosearch +dnssec +noall +cmd +comment +qu +ans +auth +nocl +nottl +nosplit +norecur -t tlsa _25._tcp.mx01.mx-hosting.ch @173.245.59.172
> >      ;; connection timed out; no servers could be reached
> >
> > Unclear why the TLSA queries are dropped, and by whom (is Cloudflare
> > just proxying breakage at the customer's DNS?)
> 
> I've looked into the error on our side and the reason for those 
> SERVFAILs are due to malformed record content. This is likely due to an 
> older version of our API not performing the correct validations for TLSA 
> records and it is unfortunate the zone owners never checked the output.

Interesting.  I would have expected the RDATA to just be opaque bytes
when stored, and the server to return what ever it had, e.g.:

    _25._tcp.smtp.example.com. IN TLSA #2 0001
    _25._tcp.smtp.example.com. IN RRSIG TLSA ...

and let the client deal with malformed RDATA.  Postfix, for example,
would handle this gracefully, treating TLSA RRs with the mtype and
associated data fields missing as "unusable", and doing mandatory
unauthenticated TLS.

-- 
    Viktor.