[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