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
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
