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

Viktor Dukhovni ietf-dane at dukhovni.org
Tue Aug 17 23:40:02 UTC 2021

> On 17 Aug 2021, at 7:27 pm, Lee <ler762 at gmail.com> wrote:
>> I am far from convinced that it is the resolvers job to enforce RDATA
>> syntax restrictions beyond what is required for a valid wire form.
>> If applications make unwarranted assumptions about the syntax of
>> DNS replies, that's surely an application bug, rather than an issue
>> in DNS.
> I disagree.  Programmers f**k up _all the time_
>  https://www.microsoft.com/en-us/securityengineering/sdl/about
>    "In January 2002, Microsoft launched its Trustworthy Computing
> initiative to help ensure Microsoft products and services were built
> inherently highly secure, available, reliable..."
> M$ is still shipping buggy software; blaming programmers hasn't helped.

We're only disagreeing about where the validation belongs, not whether
it should happen.

* An iterative resolver is definitely not the place to censor results
  based on value syntax.

* A general-purpose stub resolver that supports general (qname, type)
  queries would likewise IMHO not be a good place to do that.

* Once we get closer to the application, say getaddrinfo(3) with AI_CANONNAME,
  it is perhaps then reasonable for the C library to fail the lookup when
  the name is deemed invalid.

* But ideally, there should higher-layer validating APIs for the application
  to use, with the base APIs focused on reliably returning accurate data.

Do not open-code validation at the call sites, employ existing or write new
validating wrappers.  Tools can check that unsafe APIs aren't used outside
the modules that are doing the validation.


More information about the dns-operations mailing list