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

Petr Špaček pspacek at isc.org
Mon Aug 30 15:02:03 UTC 2021

On 17. 08. 21 22:17, Tony Finch wrote:
> Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>> If applications make unwarranted assumptions about the syntax of
>> DNS replies, that's surely an application bug, rather than an issue
>> in DNS.
> I particularly liked this paper because it's a really good example of a
> common cause of security problems: when it isn't clear whose
> responsibility it is to enforce an important restriction, in this case,
> hostname syntax vs. DNS name (lack of) syntax. And different implementers
> have made different choices, for instance whether the libc stub resolver
> enforces hostname syntax or not.
> And another classic vulnerability generator: standard APIs that make it
> easy for non-specialists to step on every rake in the grass. In this case,
> if an application needs something more fancy than getaddrinfo(), it has to
> contend with the low-level resolver API which is just about better than
> nothing for parsing DNS packets, but certainly won't help you handle names
> that ought to have restricted syntax (service names, mail domains, etc...)
> So I don't think the problems can be dismissed as simply application bugs:
> the problems come from mismatches in expectations at the boundary between
> the DNS and the applications. And the DNS is notorious (the subject of
> memes!) for being far too difficult to use correctly.

I'm late to this thread, but ...

IMHO authors of the paper highlight a valid point:

There is no _explicit_ guidance for consumers of DNS data which explains 
that results of DNS resolution process must be treated very carefully. 
It is clear to this group of DNS experts, but I think we should lend a 
helping hand to DNS consumers and at least explain why consumers have to 
check everything.

Is anyone interesting in writing a short RFC on this topic?

Petr Špaček

More information about the dns-operations mailing list