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

Petr Špaček pspacek at isc.org
Tue Aug 31 09:41:58 UTC 2021


On 30. 08. 21 18:01, Vladimír Čunát wrote:
> On 30/08/2021 17.02, Petr Špaček wrote:
>> [...] 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? 
> 
> That might serve as a good reference when some DNS expert points out to 
> others why they shouldn't be doing what they're doing. However, I don't 
> think we can expect a new RFC (by itself) to reduce these cases: *if* 
> they were reading DNS RFCs, they would've surely realized that they need 
> to be more careful.

Only if people were reading all of the DNS RFCs, but that's IMHO an 
unreasonable expectation for DNS data _consumers_ who do not (and should 
not) care about the inner workings of DNS.

The vast majority of DNS RFCs do not talk about data consumers, and the 
set of consumers is, I guess, almost disjoint with a set of DNS software 
vendors and server operators who are, I think, the primary target of the 
existing RFCs.

I would have a hard time if I wanted to send a link to relevant docs to 
an application developer who wants to use DNS data provided by a 
resolver library today. Most likely, I would require a bunch of links to 
several documents, with a custom commentary to explain which parts in 
what order to read.

For this reason, I think it would be good to have a document explicitly 
focused on consumers of DNS data. I think it should answer questions like:

- What's reasonable input to the resolver library? (E.g., an attacker 
might trick your code into calling the library with an attacker-provided 
input, etc.)
- What should you do with resolver library output? (Beware: it's binary, 
check syntax, it might be from the attacker's server, etc.)

-- 
Petr Špaček




More information about the dns-operations mailing list