Subject: [dnsext] Middleboxes and EDNS(0)

From: Paul Hoffman <[email-masked]>
Date: Sun, 14 Dec 2014 14:30:26 -0800

Greetings again. Section 6.1.1.1 of RFC 6891 says:

   OPT RRs MUST NOT be cached,
   forwarded, or stored in or loaded from master files.

Section 6.2.6 says:

   Middleboxes that simply forward requests to a recursive resolver MUST
   NOT modify and MUST NOT delete the OPT record contents in either
   direction.

If I'm a middlebox that is acting as a DNS forwarder, and I see an OPT RR on a query coming in my left side, what do I send that OPT RR out the right side? Do I follow the first or the second quote?

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Sun, 14 Dec 2014 14:42:56 -0800

My read would be, use the second quote.

I suspect the first quote is referring to caching forwarding DNS servers,
not dumb non-caching middle boxes.

I think any other interpretation creates an actual paradox, while this
reading does not.

And I think it is the only thing that enables OPT (EDNS) to work.

Brian

On Sun, Dec 14, 2014 at 2:30 PM, Paul Hoffman <[email-masked]> wrote:

> If I'm a middlebox that is acting as a DNS forwarder, and I see an OPT RR
> on a query coming in my left side, what do I send that OPT RR out the right
> side? Do I follow the first or the second quote?
>
> --Paul Hoffman
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Ray Bellis <[email-masked]>
Date: Mon, 15 Dec 2014 09:57:25 +0000

> On 14 Dec 2014, at 22:30, Paul Hoffman <[email-masked]> wrote:
> 

The second - that being consistent with RFC 5625, too.

The text in both 6891 and 5625 is supposed to relate to the case of a middlebox that just dumb proxies the DNS traffic at the (UDP) packet layer without performing any processing on that traffic other than the bare minimum necessary to get the responses back to the correct client.

Ray

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Dec 2014 07:48:41 -0800

On Dec 14, 2014, at 2:42 PM, Brian Dickson <[email-masked]> wrote:
> I suspect the first quote is referring to caching forwarding DNS servers, not dumb non-caching middle boxes.
> 
> I think any other interpretation creates an actual paradox, while this reading does not.
> 

The problem is that the first quote is in a section called "6.1.1.  Basic Elements". This seems, well, basic.

So, is this an errata for the first quote?

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Mon, 15 Dec 2014 12:57:18 -0500

> If I'm a middlebox that is acting as a DNS forwarder, and I see an OPT RR on a query coming in my left side, what do I send that OPT RR out the right side? Do I follow the first or the second quote?

Based on observation, if you are a middlebox that is acting as a DNS
forwarder, and you see an OPT RR on a query coming in your left side,
you arbitrarily choose between:
A: the first
B: the second
C: a very small rock named Edgar.

I think that the Section 6.2.6 is more correct, but middleboxes seem
to take perverse pleasure in ignoring "correct" as it related to the
DNS....

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Ray Bellis <[email-masked]>
Date: Tue, 16 Dec 2014 09:19:43 +0000

> On 15 Dec 2014, at 15:48, Paul Hoffman <[email-masked]> wrote:
>> 

I wouldn't say the first quote is incorrect - a protocol-savvy forwarder (e.g. BIND configured as a forwarder) _should_ strip EDNS options and insert its own.

IMHO the fault is in the working of the second quote, where the word "forwarder" has been used again, but in practise should probably have read "proxy".  I believe it was intended to be a nod towards this from Section 3 of RFC 5625:

 "The role of the proxy should therefore be no more and no less than to
  receive DNS requests from clients on the LAN side, forward those
  verbatim to one of the known upstream recursive resolvers on the WAN
  side, and ensure that the whole response is returned verbatim to the
  original client.

  It is RECOMMENDED that proxies should be as transparent as possible,
  such that any "hop-by-hop" mechanisms or newly introduced protocol
  extensions operate as if the proxy were not there."

Ray

---

From: Kumar Ashutosh <[email-masked]>
Date: Fri, 19 Dec 2014 04:29:32 +0000

I had a tough time interpreting this as well.
Finally closed in on:
If DNS gets OPT RR (A) in an incoming packet, it will return back the same OPT RR in the final response back to the sender.
If it needs to forward the query, DNS can chose to add new OPT RR as required for its own needs.  There is no mandate on the DNS server to keep the original OPT RR.
(needless to say the received and sent OPT RR can be also chosen to be same)

Ashu
Microsoft

-----Original Message-----
From: dnsext [mailto:[email-masked]] On Behalf Of Warren Kumari
Sent: Monday, December 15, 2014 23:27
To: Paul Hoffman
Cc: DNSEXT Group Working
Subject: Re: [dnsext] Middleboxes and EDNS(0)

> If I'm a middlebox that is acting as a DNS forwarder, and I see an OPT RR on a query coming in my left side, what do I send that OPT RR out the right side? Do I follow the first or the second quote?

Based on observation, if you are a middlebox that is acting as a DNS forwarder, and you see an OPT RR on a query coming in your left side, you arbitrarily choose between:
A: the first
B: the second
C: a very small rock named Edgar.

I think that the Section 6.2.6 is more correct, but middleboxes seem to take perverse pleasure in ignoring "correct" as it related to the DNS....

W

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Dec 2014 08:11:38 -0500

> If DNS gets OPT RR (A) in an incoming packet, it will return back the same OPT RR in the final response back to the sender.

No, that's not what the text says.   If you read the whole section, it says that if the middlebox isn't being intelligent about what's in the OPT RR, it should forward it without modification.   If it is intelligent, it is assumed to be able to do the right thing, and the interaction between it and the upstream server is a separate transaction from the interaction between it and the downstream client: that is, state must somehow be maintained.   Having implemented a proxy that fiddles with EDNS0 on the way through, this is how I handled it, and it seems to work nicely.

Section 6.1.1 says that if an OPT RR is received, one must be returned, but there is no requirement that it be the _same_ one.   Indeed, that doesn't really make sense.

Of course, I am not exactly an expert on this, so I'm curious whether the assertion I have just made will provoke a stern correction, but I would be surprised if it did.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Dec 2014 08:25:22 -0800

On Dec 19, 2014, at 5:11 AM, Ted Lemon <[email-masked]> wrote:
> No, that's not what the text says.   If you read the whole section, it says that if the middlebox isn't being intelligent about what's in the OPT RR, it should forward it without modification.   If it is intelligent, it is assumed to be able to do the right thing, and the interaction between it and the upstream server is a separate transaction from the interaction between it and the downstream client: that is, state must somehow be maintained.  

Huh? The text says no such thing, which is why I asked the question. That is a consistent interpretation, but it is certainly not in the text.

> Of course, I am not exactly an expert on this, so I'm curious whether the assertion I have just made will provoke a stern correction, but I would be surprised if it did.

When you say "the text says" and you don't quote the text, you should not be surprised.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Dec 2014 14:45:45 -0500

> Huh? The text says no such thing, which is why I asked the question. That is a consistent interpretation, but it is certainly not in the text.

Here's what the text says:

   Middleboxes that have additional functionality, such as answering
   queries or acting as intelligent forwarders, SHOULD be able to
   process the OPT record and act based on its contents.  These
   middleboxes MUST consider the incoming request and any outgoing
   requests as separate transactions if the characteristics of the
   messages are different.

> No, that's not what the text says.   If you read the whole section, it says that if the middlebox isn't being intelligent about what's in the OPT RR, it should forward it without modification.   If…

I don't see another way to read this.

Now, to be honest, I interjected here in response to Kumar Ashutosh's comment, not with the motivation of actually answering your original question.   The answer to your original question seems obvious to me: follow the advice on middleboxes.   The other advice is for DNS _servers_ of various flavors, not for middleboxes.   This seems explicit to me in the text; I can understand how you could be confused if the section on middleboxes were not present, but since it is, it doesn't make sense to prefer the other text for your use case.