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

Robert Mortimer Robert.Mortimer at nominet.uk
Wed Aug 18 14:26:46 UTC 2021

I'd be glad to have both. Yes the applications should do it either via better libraries or some other mechanism. 
But as there will always be badly written applications I'd quite like to be able to tell my local resolver "validate any response you get and reject anything that fails". It gives me better depth of protection and at a local level, be it home or business it would be good to have the choice especially if exceptions could be carved out.

If I had to bet on which would happen first/at all "resolver libraries/applications being fixed" or "A DNS resolver implementing validation" I know where my money would be. Rejecting "malformed" responses at the resolver wouldn't seem to be a good thing[tm].

-----Original Message-----
From: dns-operations <dns-operations-bounces at dns-oarc.net> On Behalf Of Viktor Dukhovni
Sent: Wednesday, August 18, 2021 2:53 PM
To: dns-operations at dns-oarc.net
Subject: Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS

> On 18 Aug 2021, at 2:27 am, Paul Vixie <paul at redbarn.org> wrote:
> 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.

I already mentioned that I am supportive of validation in the system libraries above the raw (qname, qtype) DNS lookup.  Thus in particular getaddrinfo() and getnameinfo() or per my example, new APIs that return validated TLSA records.  All such validation should be *on host*, and not delegated to remote servers.

I believe it would be a mistake to enforce syntax in off-host iterative resolvers (whether public, home or enterprise).  There's no way to know what they've validate and bypass opportunities for MiTM attacks.


dns-operations mailing list
dns-operations at lists.dns-oarc.net

More information about the dns-operations mailing list