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