Subject: [DNSOP] Clarification on EDNS 6891

From: Ray Bellis <[email-masked]>
Date: Wed, 03 Jun 2015 13:57:39 +0100

Whilst discussing 5966-bis with my co-authors connection-close with the
co-authors, we were reminded of this point I made in
draft-bellis-dnsop-connection-close in relation to §7 of RFC 6891:

"  TODO: note - the constraint in RFC 6891 appears unnecessarily strict
   - it appears to mandate that the EDNS(0) support indication is on a
   per-request basis, but it would be reasonable on a connection-
   orientated transport to assume that ANY preceding request on that
   connection with an OPT RR is sufficient to indicate that the client
   supports EDNS(0)."

Is this something that the WG believes needs to be fixed?

Ray

---

From: Shane Kerr <[email-masked]>
Date: Wed, 3 Jun 2015 16:17:04 +0000

Ray,

On Wed, 03 Jun 2015 13:57:39 +0100

> Is this something that the WG believes needs to be fixed?

The potential benefit is that a client could omit the OPT RR on
subsequent messages? Seems a relatively small benefit, and there are
costs. (Are there other benefits?)

The server would have to have some way to know what the EDNS(0) options
of subsequent messages are. A simple way would be to assume that all
subsequent messages have the same EDNS(0) unless otherwise specified.

With this setup, a client could omit the OPT RR on subsequent messages.

But the client would somehow have to know that the server acts this
way. We currently don't have any way to let the client know this. We
can add one, of course, but it seems like a relatively large amount of
work for very little gain.

Cheers,

--
Shane

---

From: "Joe Abley" <[email-masked]>
Date: Wed, 03 Jun 2015 17:22:24 +0100

> costs. (Are there other benefits?)

I agree.

I think there's a baked-in expectation that OPT pseudo-RR is included in 
every DNS message, not on every connection (where the transport is 
connection-oriented).

While the conventional case of resolver-talks-to-authority makes this 
seem like a highly pedantic observation, we can never be sure of what is 
happening behind the curtain; ALGs that bridge between transports 
(providing a UDP interface on one side but managing a TCP connection 
pool on the other, for example) exist, for example.

I think there would need to be a clear benefit before we imagined 
changing EDNS signalling semantics to be anything other than 
per-message.

Joe

---

From: Ray Bellis <[email-masked]>
Date: Mon, 08 Jun 2015 09:43:26 +0100

> every DNS message, not on every connection (where the transport is

Joe,

Part of the reason this came up is this text in
draft-ietf-edns-tcp-keepalive:

"DNS clients MAY include the edns-tcp-keepalive option in the first
 query sent to a server using TCP transport to signal their desire
 that that specific TCP session be used for multiple DNS transactions."

> pool on the other, for example) exist, for example.

Yes, an ALG such as this was the most compelling (albeit hypothetical)
reason that I could think of for not making this assumption, but then
EDNS is *supposed* to be hop-by-hop.

kind regards,

Ray

---

From: Ray Bellis <[email-masked]>
Date: Fri, 12 Jun 2015 11:52:44 +0100

> every DNS message, not on every connection (where the transport is

The use case we are considering is that absent an OPT RR in each
request, RFC 6891 doesn't permit the server to unilaterally send back an
OPT RR in a response (e.g. for connection signalling purposes) even it
one was previously seen on the same persistent connection.

Furthermore if the specification of a particular OPT code requires that
it only be sent when received from the client then that must also apply
*per message*.

We're not saying this is wrong, but in the context of a persistent
connection that could be quite an overhead and if necessary we should
explicitly document this with full awareness of the potential consequences.

It seems that EDNS is not an entirely suitable mechanism for
*connection* related signalling and it's this issue that we're trying to
find a solution to.

kind regards,

Ray

---

From: Shane Kerr <[email-masked]>
Date: Fri, 12 Jun 2015 12:07:17 +0000

Ray,

On Fri, 12 Jun 2015 11:52:44 +0100

> *connection* related signalling and it's this issue that we're trying to

Okay, perhaps I misunderstood the original question.

I was taking the question to be "in our current clarification work,
should we consider omitting OPT RR from every message on a session". In
that case, I think the answer is "no, this is not a clarification, but
a protocol change".

If the question is, "should we change the protocol so that EDNS over
connection-oriented transports works differently", then I think the
answer is, "hm... interesting. It probably won't provide a big win,
but lets explore it."

:) 

Cheers,

--
Shane

---

From: Paul Vixie <[email-masked]>
Date: Fri, 12 Jun 2015 07:46:26 -0700

Ray Bellis wrote:
> ...

connections weren't considered when EDNS was first described, nor when it was later redescribed.

i think if you're specifying an option that refers to the connection (for example, to negotiate better "close" rules than is present in raw tcp/53 today) then any responder who acks your signal can be expected to know whether it can do so honestly and effectively. if the signal's meaning is "please change to these better 'close' rules for this tcp session" then the responder should be able to say "ok i changed to these better 'close' rules for this tcp session" without worrying about whether subsequent transactions in the same session repeat this negotiation.

however, that's not the world we live in. consider for example proxy_dns (available as open source on https://github.com/BII-Lab/DNSoverHTTP) which is perfectly capable of carrying individual dns transactions over several parallel http(s) sessions, and to whom any new EDNS signalling will be opaque at least initially. this naive dns client only understands framing, not content, and it works. i think this naivety is likely present in some dns-aware load balancers as well. and i think that none of these are "broken" or in any way "noncompliant".

furthermore, proxy-dns will use TCP on the regenerated far-end DNS transaction if it heard the original near-side DNS transaction via TCP. therefore even without multiplexing, putting a connection level negotiation into the OPT could make this TCP initiator ask (by opaquely carrying its payload) for something it doesn't understand and promise to do something it won't do.

a rule of protocol evolution is, existing speakers should not become broken due to a spec change.

so, connection semantics will have to be negotiated at the framing level not the content level.

so, you might explore the use of a zero length request, which currently means nothing.

vixie

-- 
Paul Vixie

---

From: Ray Bellis <[email-masked]>
Date: Fri, 12 Jun 2015 16:05:31 +0100

On 12/06/2015 15:46, Paul Vixie wrote:

> i think if you're specifying an option that refers to the connection
> (for example, to negotiate better "close" rules than is present in
> raw tcp/53 today) then any responder who acks your signal can be
> expected to know whether it can do so honestly and effectively. if
> the signal's meaning is "please change to these better 'close' rules
> for this tcp session" then the responder should be able to say "ok i
> changed to these better 'close' rules for this tcp session" without
> worrying about whether subsequent transactions in the same session
> repeat this negotiation.

That would be ideal, yes.

> however, that's not the world we live in. consider for example
> proxy_dns (available as open source on
> https://github.com/BII-Lab/DNSoverHTTP) which is perfectly capable of
> carrying individual dns transactions over several parallel http(s)
> sessions, and to whom any new EDNS signalling will be opaque at least
> initially. this naive dns client only understands framing, not
> content, and it works. i think this naivety is likely present in some
> dns-aware load balancers as well. and i think that none of these are
> "broken" or in any way "noncompliant".

I think there's scope for a long argument on this last point.

RFC 2671 (§4.1) says "OPT RRs shall never be ... forwarded".

RFC 6891 is even more explicit in §6 about middleboxes.

It's perhaps a shame that EDNS doesn't support the separation of
"hop-by-hop" options vs "end-to-end" options that IPv6 has.

To my mind proxy_dns is absolutely non-conformant, but clearly *some*
EDNS options may be safely forwarded whilst others shouldn't be.
However without a separation in the option number space (or a brand new
OPT-alike RR) there's no way for an implementation to know without it
being hard-coded for each then-known option.

> furthermore, proxy-dns will use TCP on the regenerated far-end DNS
> transaction if it heard the original near-side DNS transaction via
> TCP. therefore even without multiplexing, putting a connection level
> negotiation into the OPT could make this TCP initiator ask (by
> opaquely carrying its payload) for something it doesn't understand
> and promise to do something it won't do.
> 

If only that were existing _conformant_ speakers ;-)

> so, you might explore the use of a zero length request, which

The issue with that (and potentially anything else we might come up
with) is that there's no guarantee *whatever we write* that some naive
non-conformant implementation will find a way to forward the magic sequence.

kind regards,

Ray

---

From: Paul Vixie <[email-masked]>
Date: Fri, 12 Jun 2015 09:49:58 -0700

> RFC 2671 (§4.1) says "OPT RRs shall never be ... forwarded".

as the author of that text, i claim that i was referring to DNS
Forwarding, in the sense described by
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-terminology/>.

> RFC 6891 is even more explicit in §6 about middleboxes.

in RFC 6891 (6.8.2) i see this text:

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

in which case, proxy_dns is precisely compliant with the currently
described EDNS0 specification.

> "hop-by-hop" options vs "end-to-end" options that IPv6 has.

indeed, this is why extended label types were removed from the EDNS0
definition.

> To my mind proxy_dns is absolutely non-conformant, ...

can you explain why or how, in light of the observations i shared above?

> If only that were existing _conformant_ speakers ;-)

i see your smiley so i'm not going to provide a serious rejoinder.
proxy_dns is conformant to the literal text of RFC 6891, to the author's
intent of RFC 2671, and with all pure non-EDNS implementations of RFC 1035.

if any part of 2671 or 6891 would make any speaker of 1035 (and any
deprecations such as 3425 or 4159) wrong, then that part of 2671 or 6891
would itself be wrong and must be stricken.

if we want to make a non-backward-compatible change to 1035, we have to
write a deprecation RFC and get that approved.

> non-conformant implementation will find a way to forward the magic sequence.

understood. we had this problem with the Z bits in RFC 1035, too, since
they were simply copied by a lot of naive responders (such as BIND 4).

as you know, my top preference is still that you define a new port
number having different connection-close rules. tcp/53 is so widely
blocked that i don't think you'll get worse service on tcp/666 or whatever.

as you know, my actual solution to this is proxy_dns, which leverages
both the wider reachability of tcp/443 and the better connection
management of https.

however, i think you can find meat on this bone if you keep gnawing. for
example what if you require a specific response to a zero length
message, like <9>EDNS_HERE or some other marker, which is considerably
unlikely to occur in nature, and if not seen, signals by its absence a
cacheable condition known as "this server did not agree to the new
connection-close rules".

every signal we have at present is either end-to-end (talking about
authoritative data) or hop-by-hop (talking about the current
transaction's endpoints). we don't have anything having to do with
framing, nor do we have a place to put a new signal that won't be
interpreted as either end-to-end or hop-by-hop by some perfectly
conformant endpoint or middlebox that got here first.

-- 
Paul Vixie

---

From: Ray Bellis <[email-masked]>
Date: Fri, 12 Jun 2015 20:14:49 +0100

> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-terminology/>.

Yes, that's reasonable.

> described EDNS0 specification.

I don't believe the word "forward" in RFC 6891 is intended the same as
that in RFC 2671.

I did specifically raise this whole middlebox issue while RFC 6891 was
being written (which is possibly why a lot of §6 is actually there)
since whilst researching SSAC 035 and RFC 5625 I found quite a lot of
"forwarders" (or "ALGs" or "proxies" of whatever we want to call them)
that interfered with EDNS.

The intent I had hoped 6891 would express is that if you do _absolutely
nothing_ except receive packets on one side and "forward" them untouched
to the server (using the *same* protocol), and likewise with the
responses, then you are not a "hop" in the EDNS sense and may (indeed
MUST) pass EDNS untouched.  That's mostly also what §3 of RFC 5625 is
trying to say.

However if you do anything the slightest bit more complicated than that
then you should be considered a hop, and NOT pass on the OPT RR.

[ That's not to say that such a proxy that knows about OPT RRs
  couldn't decide to pass on a specific value option in its own
  OPT RR if it understands the semantics of that option. ]

> indeed, this is why extended label types were removed from the EDNS0

Right

> can you explain why or how, in light of the observations i shared above?

See above - it (potentially) multiplexes multiple clients onto a single
upstream connection.  IMHO it's not "dumb enough" to satisfy §3 of RFC
5625 and by extension §6 of RFC 6891.

> would itself be wrong and must be stricken.

I am not aware of any explicit incompatibility between EDNS and RFC
1035, but that is an interesting point.  As you say, there's nothing in
pure non-EDNS RFC 1035 semantics that breaks when you multiplex multiple
clients down a single TCP session.  [Given typical current TCP/DNS
behaviour of sending responses strictly in request order it would
perhaps be very inefficient, though]

Are there perhaps hidden, implicit incompatibilities?  I guess that
depends on what the consensus view of conformance is.

> write a deprecation RFC and get that approved.

Indeed - and not an easy task.

> both the wider reachability of tcp/443 and the better connection

I'm not sure I've seen you state it quite this unambiguously before, but
yes, understood.

> cacheable condition known as "this server did not agree to the new

A naive enough proxy could still relay on the zero length request
upstream and send back the magic response, making the client believe
that the proxy it's talking to supports the signaling when it fact it's
only the upstream that does.

> conformant endpoint or middlebox that got here first.

Hence the argument about "conformance" :)

kind regards,

Ray

---

From: Paul Vixie <[email-masked]>
Date: Fri, 12 Jun 2015 15:29:42 -0700

> I don't believe the word "forward" in RFC 6891 is intended the same as

i think i disagree. see below.

> MUST) pass EDNS untouched.  ...

ok.

> then you should be considered a hop, and NOT pass on the OPT RR.

to that terminological hair splitting, my answer is: the combination of
the two proxy_dns agents (the near end that is a DNS listener, and the
far end that is a DNS re-initiator) plus the HTTP(S) transport between
them, is exactly the same as what you said: "do absolutely nothing
except rcv pkts on one side and fwd them untouched to the server (using
the same protocol)".

> 5625 and by extension §6 of RFC 6891.

since 6891 is talking about the forwarding of transactions not of
sessions, multiplexing is a distinction without a difference.

> Indeed - and not an easy task.

there's good reason why it's not easy. getting consensus that breaking
old behaviour won't hurt any working configurations is hard. that said,
we reached such consensus on removing IQUERY and on removing IP6.INT, so
it can be done. i judge that it could not be done for violating the
connection close assumptions of RFC 1035-conformant TCP initiators and
responders, though.

> only the upstream that does.

yeah you're right. middleboxes, as we know, are evil.

-- 
Paul Vixie