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

[Christian Elmerot]

On 27/05/2020 22:11, Viktor Dukhovni wrote:
> On Wed, May 27, 2020 at 04:35:29PM -0400, Dave Lawrence wrote:
>
>> Viktor Dukhovni writes:
>>> 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.
>> ... you would expect a DNS server to not do validation on the RDATA of
>> known types and just serve whatever was stuffed in there?
> Yes, precisely.  The time to validate input is before the records are
> inserted into the zone database.  Once the records are there, (modulo
> special considerations around name compression) I'd expect them to be
> just binary blobs to be served to clients as-is.

While that in theory is true or how it is handled the SERVFAIL is 
introduced into the equation when DNSSEC live signing is applied to make 
the RRSIG of said content. Some bytes simply does not lend themselves to 
that operation, at least on our setup. Not sure providing an erroneous 
payload with a missing RRSIG would be handled better by clients than a 
SERVFAIL. The proper fix here is to fix the record contents going into 
the signing operation.


> So for something like a TLSA record, I'd expect a server to just return
> an opaque payload.  Thus, for example, I would also not expect the still
> unresolved Verisign public DNS mangling of the army.mil SOA:
>      $ dig +nocl +nottl +noall +ans -t soa army.mil @64.6.64.6
>      army.mil. SOA ns01.army.mil. usarmy.huachuca.netcom.mesg.epdns-global.mail.mil. 2007170737 900 90 2419200 300
>
> when the correct SOA RDATA is:
>
>      $ dig +nocl +nottl +noall +ans -t soa army.mil @1.1.1.1
>      army.mil. SOA ns01.army.mil. usarmy\.huachuca\.netcom\.mesg\.epdns-global.mail.mil. 2007170737 900 90 2419200 300
>
> which breaks denial-of-existence for this zone for any downstream
> validators, ...

I'm not quite sure I'd expect validators to handle the erroneous TLSA 
payload proper if they can't deal with that mailformed SOA.

/Christian Elmerot, Cloudflare DNS team