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

[Viktor Dukhovni]

On Tue, Aug 17, 2021 at 05:49:04PM -0600, Paul Ebersman wrote:

> DNS is a complicated, esoteric knowledge set. The reason apps,
> middleware and various other boxes mucking with DNS in transit tend to
> suck is exactly because the programmers on those boxes don't have this
> expertise and make all sorts of bad assumptions about what is safe/sane.
> 
> Resolver coders are vastly more likely to have knowledge of what might
> break, what is unsafe, etc. And if they miss a check, the odds of said
> resolver coders finding this out quickly, and fixing it and getting it
> deployed, are much better than expecting apps or middleware box
> developers to do so.

The middleboxes will get it wrong, and will have stale firmware for
decades.  Do not place your trust in middleboxes.  They'll fuck up PTR
indication for CIDR blocks where intermediate CNAMEs may contain "/"
characters, they'll not know how to validate less popular and/or new
record types, ...

The sanest viable place to do *some* common validation is in stub
resolvers that support type-specific lookup functions above the
basic (qname, qtype) interface, also perhaps in the system nsswitch
and getaddrinfo()).

The buck stops at the actual application libraries that use DNS for
specific purposes:

    * Parsing HTTPS/SVCB records as part of HTTP connection establishment
    * Parsing DANE TLSA records for peer certificate verification
    * ...

Let's have lots of high quality libraries, but let's not break iterative
resolvers or introduce long-term middlebox DNS breakage.

Many extant half-arsed middleboxes drop queries for unrecognised qtypes,
or return NOTIMP instead of NXDOMAIN/NODATA, or otherwise cut corners.

No thanks!

-- 
    Viktor.