[dns-operations] DNS cookies in a mixed resolver anycast environment

[Ondřej Surý]

> On 3 Jun 2019, at 14:13, Tobias S. Josefowitz <t.josefowitz at gmail.com> wrote:
> 
> On Mon, Jun 3, 2019 at 11:45 AM Ondřej Surý <ondrej at sury.org> wrote:
>> 
>> Reading the RFC 6891 that you quote would help, just the full Section 7 would be enough:
>> 
>> https://tools.ietf.org/html/rfc6891#section-7
> 
> I read it thrice more now - and I do not get it. Is it because
> standards compliant responders pre-EDNS never had any chance to
> respond anything but a FORMERR once something as odd as an OPT showed
> up in the additional section of the query?

Let’s assume that DNS resolver sends EDNS enabled query, now you have three options:

1. answer contains FORMERR with OPT —> the other side speaks EDNS and it means the EDNS contents were bogus, and you return error to the client

2. answer contains FORMERR without OPT —> the other side understands EDNS, but refuses to speak EDNS, the resolver needs to retry without EDNS or the other side doesn’t understand EDNS and is strict in parsing

3. answer contains NOERROR without OPT —> the other side doesn’t understands EDNS, e.g. pre-EDNS server, process the answer as usual

4. only pain and suffering here (f.e. no answer at all) —> leads to timeouts, or straight failure etc.

So, when you want to implement new DNS server because you think DNS is easy, just don’t… and if you don’t listen, just make sure you are not in the 4th category.

The list might be incomplete, but the important distinction is between FORMERR+OPT and FORMERR, e.g. the worst thing you can do is not start the answer from scratch, but copy the query and modify bits and pieces.

Ondrej
--
Ondřej Surý
ondrej at sury.org