[dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS

[Paul Vixie]

On Wed, Aug 18, 2021 at 12:56:14AM -0400, Viktor Dukhovni wrote:
> On Wed, Aug 18, 2021 at 03:48:03AM +0000, Paul Vixie wrote:
> 
> > On Wed, Aug 18, 2021 at 07:12:32AM +1000, Mark Andrews wrote:
> > > ... Everything that comes off the wire needs to be checked.
> > > Occasionally some checks will be missed.
> > 
> > check everything, like marka said. bounce bad stuff often. make problems
> > hot, early, and fast, for implementations by fresh undamaged programmers
> > who are ready to declare "works for me" and take off for their weekend.
> 
> Yes, but *where*?  Do you concur that it is the resolver's job to
> check RDATA element syntax?

yes.

>    - For which RRtypes?

all of them. and each RR type should have an Rdata schema described for it
in some RFC, including both the syntactic _and semantic_ constraints for it.

>    - Using what syntax rules?

hard coded. whenever we need to broaden constraints we should be burning a
code point (like AAAA after A) rather than trying to dynamically describe
the constraints in machine-readable form.

>    - Should resolvers e.g. check that "3 1 0" TLSA records hold
>      a well-formed X.509 SubjectPublicKeyInfo DER octet-string?
>      Or that "3 0 0" holds a well-formed X.509 certificate?

yes.

>    - Should CNAMEs be valid DNS hostnames?  Or are CNAMEs in
>      reverse (PTR) lookups more equal than others?  (Since they
>      sometimes take special forms to encode CIDR delegations?

i never defined the "hostname" constraint from libresolv in any RFC. my rule
was just, it had to match the old HOSTS.TXT rules. if noone has any will to
formalize that, then it ought to be ignored.

note that because a PTR can (after RFC 2317) point to a non-canonical name
(which is the owner of a CNAME RR), we ought to have revised the PTR
specification to describe its target as non-canonical. i plead laziness.

note that because a CNAME can point to a CNAME (even in RFC 1034), its
target is _not_ and never was canonical, and this is an error in RFC 1034,
which some non-lazy person should take pen in hand and fix. only the final
CNAME target in a chain of CNAMEs is "canonical".

> I'm all for better libraries (I've contributed a number of improvements
> to the Haskell Network.DNS library), but I am not keen to see resolvers
> doing well-meaning, but always incomplete and difficult to rely on
> validation.

i urge you to reconsider your position. apps should be calling things like
getnameinfo() and getaddrinfo(), and those should fail early and often if
their expectations are not met. that's what shared libraries are for, and
that's what a 64K codepoint space is for.

-- 
Paul Vixie