Subject: Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Apr 2018 17:33:27 +1000

This is intended to do what?  Indicate where the response came from?
Why does the client care?  I assume that it doesn't apply to requests,
or that would get into draft-bellis-dnsop-xpf territory.

BTW, you really need to drop UDP from the media type name now.
application/dns-udpwireformat;original_transport=tcp is a bit of a
contradiction.

On Mon, Mar 26, 2018 at 4:48 PM, Paul Hoffman <[email-masked]> wrote:
> Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining a new media type seems like overkill, particularly given that it will be transporting *the exact same* data as an existing media type. Instead, an optional parameter could be added to the application/dns-udpwireformat registration in the DOH document.
>
> Proposal:
>
> =====
>
> In the media type definition, change "Optional parameters" to:
>
> Optional parameters: original_transport
>    original_transport has two defined values, "udp" and "tcp".
>    This is only expected to be used by servers.
>
> Also in the the DOH document, under Operational Considerations, we would add:
>
> This protocol does not define any use for the original_transport optional
> parameter of the application/dns-udpwireformat media type.
>
> =====
>
> Then draft-ietf-dnsop-dns-wireformat-http could define the use of that optional parameter as it sees fit.
>
> --Paul Hoffman
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh

---

From: Davey Song <[email-masked]>
Date: Tue, 3 Apr 2018 17:44:55 +0800

On 3 April 2018 at 15:33, Martin Thomson <[email-masked]> wrote:

> Why does the client care?

To keep the proxy (API client and server) transparent and bypass the
middlebox along the path. Without the indicate, the API server has no clue
what transport the client use (or would like to use. because there maybe
cases that client would like to test TCP capablity of the far end resolver,
I don't know). If no such indicate, It is either always using UDP or TCP by
default (or by local configuration). It can be done as an choice for
software implementation, but for protocol design IMHO, a indicate should be
introduced to provide that information.

> I assume that it doesn't apply to requests,
That's is the quesion whether the indicate should be carried in HTTP layer
or DNS layer. If we use HTTP as a tranparent tunnel without any
modification on upper layer message, I would prefer to use a HTTP indicate.

> application/dns-udpwireformat;original_transport=tcp is a bit of a

I agree.  I find no harm defining a media type "application/dns-wireformat"
for DOH.

Davey

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Apr 2018 19:58:46 +1000

If I understand your response (not sure that I do), that seems pretty
academic and not at all persuasive.  For instance, if a client cared
about testing TCP capabilities, it can always do its own resolution.

On Tue, Apr 3, 2018 at 7:44 PM, Davey Song <[email-masked]> wrote:
> or DNS layer. If we use HTTP as a tranparent tunnel without any modification
> on upper layer message, I would prefer to use a HTTP indicate.
>
>>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Apr 2018 13:27:20 +0000

On Apr 3, 2018, at 2:58 AM, Martin Thomson <[email-masked]> wrote:
> academic and not at all persuasive.  

...to you. It was persuasive enough for the DNSOP WG to adopt the document as a WG item.

> For instance, if a client cared

That's not what draft-ietf-dnsop-dns-wireformat-http is about.

Martin: Are you saying that you want DOH to remove the optional parameter from the application/dns-udpwireformat registration? If so, what do you propose for the DNSOP WG?

--Paul Hoffman

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 3 Apr 2018 13:00:42 -0400

> about testing TCP capabilities, it can always do its own resolution.

That testing TCP capabilities part is a distraction from the core
motivation.  The request makes sense from a dumb transparent proxy
point of view, where there's a regular DNS resolver on the one end who
just wants to be able to get DNS messages through an HTTPS tunnel.
Media type isn't the right way to achieve that, but the key idea is sound.

---

From: Davey Song <[email-masked]>
Date: Wed, 4 Apr 2018 10:15:47 +0800

> about testing TCP capabilities, it can always do its own resolution.

It's not the emphasis. Peopole get tied of misbehavior (or unexperect
behavior) of all kinds of middlebox. I just think DOH proxy should not add
any fuel on that.

Davey

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Apr 2018 12:35:34 +1000

> Martin: Are you saying that you want DOH to remove the optional parameter from the application/dns-udpwireformat registration? If so, what do you propose for the DNSOP WG?

Right now, abandon draft-ietf-dnsop-dns-wireformat-http.  But I'll
concede that I'm probably missing something.

By my current understanding, draft-ietf-dnsop-dns-wireformat-http is
indistinguishable from a specific implementation of
draft-ietf-doh-dns-over-https.  That is, if a DOH server wanted to
service all its queries by forwarding requests to a resolver [1], I
can't see how that would be disallowed by DOH, and that's exactly what
draft-ietf-dnsop-dns-wireformat-http appears to describe.

Convince me that this isn't the case (or not, and I'll be in the rough on this).

--Martin

[1] ...after randomizing the ID.

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 3 Apr 2018 23:39:27 -0400

> concede that I'm probably missing something.

I think that's right.  -05 with the original_transport optional
parameter accommodates the aims of that other draft.

---

From: Davey Song <[email-masked]>
Date: Wed, 4 Apr 2018 12:45:29 +0800

I'm sorry to hear that. I would like to provide some information as a
background if it's useful.

dns-wireformat-http draft was originally proposed in DNSOP WG as a
experimental draft in early 2016. We focus on the requirement of enhancing
DNS availability bypassing the middlebox on the path via HTTP tunnel.  It
was later adopted in DNSOP WG as WG document. I think it was an original
and sound work deserving us to work on at that time.

However, it was postponed in 2017 and we are told that HTTP people has
concern on it.  At that time, draft-hoffman-dispatch-dns-over-https was
proposed as a standards track aiming to defined HTTPS as substrate
transport for DNS which is different from the DNS over HTTP tunnel case.

Later DOH was created forcusing on HTTPS as DNS transport protocol. We were
told that the proxy and tunnel case is not in the scope of DOH but we are
suggested use the technology developed in DOH. At that time I still think
it is valuable to introduce a use case of DNS over HTTP tunnel and define
necessary protocol. The compromise is that we drop the free use of
HTTP(without TLS) and HTTP 1.x because DOH has mandatory requirement on
HTTPS and HTT /2.

When I submited dnsop-dns-wireformat-http-02 weeks ago, I asked if we could
introduce a optional parameter which is bettern than a new media type
"application/dns-tcpwireformat". I suppose that optional parameter should
defined in dnsop-dns-wireformat-http-02 instead of DOH draft. However,
after original_transport optional parameter was defined in 05 version of
doh draft, I'm afraid it was enlarged its scope to contain the proxy/tunnel
case which make people think dns-wireformat-http is useless. I'm confused.

So I would like to ask folks in the two WGs how to proceed:

1) Should dns-wireformat-http draft insists on the original defination of
DNS over HTTP(s) tunnel with new HTTP header as a experimental document?
Because that is the original experiment we have done to show the capacity
of DNS over HTTP(s).
2) If the answer is no, how should  dns-wireformat-http draft align itself
with DOH document. My suggestion is to define the original_transport
optional parameter in  dns-wireformat-http draft.

Or Is there any other way out not abandoning our work? As the co-author I
still want to rescue it.

-Davey

On 4 April 2018 at 10:35, Martin Thomson <[email-masked]> wrote:

> > Martin: Are you saying that you want DOH to remove the optional
> parameter from the application/dns-udpwireformat registration? If so, what
> do you propose for the DNSOP WG?
>

---

From: Ray Bellis <[email-masked]>
Date: Wed, 4 Apr 2018 10:32:50 +0100

[added DOH WG to the cc:]

On 04/04/2018 04:39, Dave Lawrence wrote
> parameter accommodates the aims of that other draft.

but ignores the concerns I raised yesterday that simply indicating "tcp"
or "udp" is insufficient to allow a server to make policy decisions
based on the meta-properties of the original request and its transport
(whether that be a "real" tranport protocol like UDP or TCP or a
pseudo-transport like DNS-o-TLS, or DNS-o-QUIC, etc).

Ray

---

From: Ray Bellis <[email-masked]>
Date: Wed, 4 Apr 2018 15:22:00 +0100

On 04/04/2018 13:20, Paul Vixie wrote:

> tcp and udp are the two ways a query might have reached the
> initiating proxy, and that distinction is the only thing the
> responding proxy needs to know.

I disagree, I don't think that transport protocols should continue to be
used as things that should be used for policy decisions.

Per my previous message, they were a suitable proxy (no pun intended)
for "this came from an unspoofable address", or "this channel can handle
large responses" but there are other ways to achieve that now that
aren't strictly transport.

For example, presence of EDNS cookies satisfies the "unspoofable
address" and therefore would permit RRL to be skipped for that client,
but "UDP with Cookies" isn't a transport.

[I appreciate that this isn't the best example because that cookie
*might* get all the way through to the backend server anyway.  But it
also might not].

> if DOH becomes a standard transport, then we could add that 
> identifier as well -- but i don't think a client capable of DOH is
> going to be using this particular proxy method.

We already have DNS-over-TLS, DNS-over-DTLS, and folks are working on
DNS-over-QUIC too.  None of those are true "transports", but server
operators may wish to make policy decisions based on the resulting
meta-properties of them.

Ray

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Apr 2018 07:54:04 -0700

ray, i won't engage on the question, should i want to do this. the 
working group mantra is interoperability -- as in, if you want to do 
this, here's an interoperable way. i'm not asking that the working group 
ratify the intent, or recommend the method. (as went ECS.)

the proxy is transparent. we list it in resolv.conf or as a forwarder. 
it regenerates the queries on the far side. it has to differentiate 
between tcp and udp because the unmodified client is making strategy 
decisions and implementing those using that transport choice.

this is not a service. DOH is a service. this is a proxy, which i would 
like to have be interoperable. please don't ask me to change what i want 
to build; that would be out-of-scope.

paul

re:

Ray Bellis wrote:
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Apr 2018 11:14:04 -0400

On Apr 4, 2018, at 10:54 AM, Paul Vixie <[email-masked]> wrote:
> this is not a service. DOH is a service. this is a proxy, which i would like to have be interoperable. please don't ask me to change what i want to build; that would be out-of-scope.

Maybe another question to ask is "okay, Paul wants to build this, but why does the IETF need to standardize it?"

I don't mean that the answer should be "it doesn't," but rather that I don't actually see why this is valuable, and maybe I'm not the only one who needs to hear more of a sales pitch.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 4 Apr 2018 16:36:56 +0100

> to build; that would be out-of-scope.

I'm not sure that we're talking about the same sort of proxy.

I'm more concerned with the sort that might sit on the (far) server side
of the equation, proxying between a DOH server and a real DNS server
where those two servers are cooperating.

This is (IMHO) a likely deployment model for DOH, until such time as the
major OSS DNS server implementations include DOH natively.

I'm therefore also concerned with how transport (or pseudo-transport)
properties affect how those real DNS servers make policy decisions about
their responses.

Ray

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Apr 2018 08:37:03 -0700

Ted Lemon wrote:
> On Apr 4, 2018, at 10:54 AM, Paul Vixie <[email-masked]
> <mailto:[email-masked]>> wrote:
>> this is not a service. DOH is a service. this is a proxy, which i
>> would like to have be interoperable. please don't ask me to change
>> what i want to build; that would be out-of-scope.
>
> Maybe another question to ask is "okay, Paul wants to build this, but
> why does the IETF need to standardize it?"

same as for ECS: not universally popular, but better if interoperable.

> I don't mean that the answer should be "it doesn't," but rather that I
> don't actually see why this is valuable, and maybe I'm not the only one
> who needs to hear more of a sales pitch.

there's code that implements this. there are people using it. there will 
be more of both. a standard will mean greater interoperability.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Apr 2018 11:41:27 -0400

On Apr 4, 2018, at 11:37 AM, Paul Vixie <[email-masked]> wrote:
> there's code that implements this. there are people using it. there will be more of both. a standard will mean greater interoperability.

Why was the code written?   Why are they using this?   What is it about this solution that makes it preferable, for their use case, to a smart proxy that is itself a full-service resolver and thus shouldn't tunnel information about the query transport?

Given Bert's talk on camels, I think these are questions that are worth asking, and the answer shouldn't be "because."

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Apr 2018 08:49:09 -0700

Ted Lemon wrote:
> On Apr 4, 2018, at 11:37 AM, Paul Vixie <[email-masked]
>> there's code that implements this. there are people using it. there
>> will be more of both. a standard will mean greater interoperability.
>
> Why was the code written? Why are they using this?

where the client can't be upgraded to DOH, and the network can't be 
upgraded to add VPN's, this allows a name server to be reachable with 
full fidelity (no middleboxes, so EDNS works) and better-than-cleartext 
privacy. i use it on my laptop when in a hotel room or coffee shop.

> What is it about this
> solution that makes it preferable, for their use case, to a smart proxy
> that is itself a full-service resolver and thus shouldn't tunnel
> information about the query transport?

this is a far thinner solution than a full-service resolver, which would 
require local configuration and monitoring and so on, as well as 
topology stability that can't be guaranteed.

> Given Bert's talk on camels, I think these are questions that are worth
> asking, and the answer shouldn't be "because."

this would never be part of the mandatory-to-implement "DNS core".

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Apr 2018 11:51:33 -0400

On Apr 4, 2018, at 11:49 AM, Paul Vixie <[email-masked]> wrote:
> this is a far thinner solution than a full-service resolver, which would require local configuration and monitoring and so on, as well as topology stability that can't be guaranteed.

For your laptop use case, why wouldn't you just have the thing running on the laptop do truncation if the answer is too long?   I admit that this is more code, but it's not a lot more code, and what you're doing instead is pretty hacky.

The fact that it's not required to implement doesn't mean that it doesn't contribute to the camel problem.

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Apr 2018 17:01:51 +0100

> where those two servers are cooperating.

In this situation it is much simpler to set them up to never use UDP.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Irish Sea: North 6 to gale 8, backing south 4 or 5. Moderate or rough,
becoming slight. Showers then fair. Good.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Apr 2018 09:30:38 -0700

Martin Thomson wrote:
> On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman<[email-masked]>  wrote:

the use case is not well-expressed. as a co-author, i apologize.

> draft-ietf-dnsop-dns-wireformat-http appears to describe.

it's a high-fidelity virtual middlebox, to work around low-fidelity 
actual middleboxes. it is not a new dns transport protocol, which would 
require client and server changes. dns-over-https is a thin drop-in.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Apr 2018 09:31:00 -0700

> parameter accommodates the aims of that other draft.

yes.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Apr 2018 09:42:20 -0700

Ted Lemon wrote:
> On Apr 4, 2018, at 11:49 AM, Paul Vixie <[email-masked]
>> this is a far thinner solution than a full-service resolver, which
>> would require local configuration and monitoring and so on, as well as
> For your laptop use case, why wouldn't you just have the thing running
> on the laptop do truncation if the answer is too long?

that would be low fidelity. i need to run clients whose internet 
experience will not be influenced by middleboxes.

> I admit that this is more code, but it's not a lot more code, and
> what you're doing instead is pretty hacky.

feel free to try it out:

https://github.com/BII-Lab/DNSoverHTTP

or:

https://github.com/BII-Lab/DNSoverHTTPinGO

these are out of date with respect to the current draft, but each works. 
i would like to see a standard that they can conform to, so that i'm 
safe building a larger infrastructure.

> doesn't contribute to the camel problem.

are we at the point where any of us can call anything we see no use for 
part of the camel problem? i'm hoping not, and so i'm going to ignore 
your statement here.

"if you want to do this, here's an interoperable method" is this group's 
meme. it's not "this is the best engineering solution we were able to 
create for the problem we are willing to admit you might have."

-- 
P Vixie

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 4 Apr 2018 12:44:48 -0400

If the stub and forwarder are both on your laptop, why do you need to
truncate?  Local UDP should have extremely large MTU.

On Wed, Apr 4, 2018 at 12:42 PM, Paul Vixie <[email-masked]> wrote:

> these are out of date with respect to the current draft, but each works. i
> would like to see a standard that they can conform to, so that i'm safe
> building a larger infrastructure.
>
> part of the camel problem? i'm hoping not, and so i'm going to ignore your
> statement here.
>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Apr 2018 09:46:12 -0700

> truncate?  Local UDP should have extremely large MTU.

i know this was addressed to me, but i didn't mention truncation, so 
it's to me a nonsequitur.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Apr 2018 13:19:21 -0400

On Apr 4, 2018, at 12:42 PM, Paul Vixie <[email-masked]> wrote:
> that would be low fidelity. i need to run clients whose internet experience will not be influenced by middleboxes.

I'm having trouble figuring out where a middlebox would be here that would reduce fidelity.   Isn't the point of what you're doing to completely bypass any middleboxes that are in the way?

I think the diagram looks like this:

LAPTOP<----link a---->DNS-over-https-proxy<---link b--->Full Service Resolver<---internet--->Authoritative servers

Where is the middlebox that's going to reduce fidelity?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Apr 2018 10:23:16 -0700

Ted Lemon wrote:
> On Apr 4, 2018, at 12:42 PM, Paul Vixie <[email-masked]
> I'm having trouble figuring out where a middlebox would be here that
> would reduce fidelity. Isn't the point of what you're doing to
> completely bypass any middleboxes that are in the way?
>
> LAPTOP<----link a---->DNS-over-https-proxy<---link b--->Full Service
> Resolver<---internet--->Authoritative servers
>

you've cut too much context. my answer was to "just truncate". your 
followup is about "which middlebox."

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Apr 2018 13:30:45 -0400

On Apr 4, 2018, at 1:23 PM, Paul Vixie <[email-masked]> wrote:
> you've cut too much context. my answer was to "just truncate". your followup is about "which middlebox."

> that would be low fidelity. i need to run clients whose internet experience will not be influenced by middleboxes.

So you've said that the client's experience will be influenced by middleboxes.   I'm trying to understand what the scenario is where this would happen.   Hence my diagram:

That is, what is the problem you are trying to avoid that requires the proxy to transparently tunnel rather than simply answering the query?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Apr 2018 11:35:24 -0700

Ted Lemon wrote:
> On Apr 4, 2018, at 1:23 PM, Paul Vixie <[email-masked]
> So you've said that the client's experience will be influenced by
> middleboxes.

i intended this to be heard as "will otherwise be influenced by 
middleboxes".

> I'm trying to understand what the scenario is where this
> would happen. Hence my diagram:
>
> That is, what is the problem you are trying to avoid that requires the
> proxy to transparently tunnel rather than simply answering the query?

the proxy is transparent. from https://github.com/BII-Lab/DNSoverHTTP:

> The proxy service does not interpret the DNS query or response in any
> way. It could be DNS, EDNS, or something not yet invented at the time
> of this writing. The only requirement is that each request message
> solicits exactly one response message. If anything at all goes wrong
> with the proxy service, the stub client will hear a DNS SERVFAIL
> response.

i intend that the endpoints (who are real dns speakers and listeners) be 
able to evolve, or never evolve, according to their own drumbeats.

the real middlebox that's otherwise in the way is in my hotel room or 
coffee shop, and knows that udp/53 is a service address, and 
policy-routes my dns traffic to its own agent, which thinks it knows 
what DNS has to look like, and can't handle modern (1999-era) extensions 
like EDNS.

by putting these messages inside https (a virtual high fidelity middle 
box), i make them invisible to the hotel's physical low fidelity middle 
box. and by respecting the originator's transport choice, i remain 
transparent to its strategy to use edns-512, edns-1280, tcp, dns, and so 
on, in whatever order it wants to do.

could this be done with a resolver using non-proxy DOH as a transport to 
its forwarder? sure. but that puts semantic intelligence in the middle, 
which will introduce configuration, logging, monitoring, diagnosis, 
upgrade, and patching costs. i don't want those here.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Apr 2018 14:44:53 -0400

On Apr 4, 2018, at 2:35 PM, Paul Vixie <[email-masked]> wrote:
> could this be done with a resolver using non-proxy DOH as a transport to its forwarder? sure. but that puts semantic intelligence in the middle, which will introduce configuration, logging, monitoring, diagnosis, upgrade, and patching costs. i don't want those here.

So essentially this is {UDP | TCP}-over-HTTPS, with constraints on the destination port?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Apr 2018 11:57:45 -0700

Ted Lemon wrote:
> On Apr 4, 2018, at 2:35 PM, Paul Vixie <[email-masked]
>> could this be done with a resolver using non-proxy DOH as a transport
>> to its forwarder? sure. but that puts semantic intelligence in the
>> middle, which will introduce configuration, logging, monitoring,
>> diagnosis, upgrade, and patching costs. i don't want those here.
>

no. it uses a DNS response message of rcode SERVFAIL for error 
signalling. so, it is as transparent as possible, and no more.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Apr 2018 15:12:12 -0400

On Apr 4, 2018, at 2:57 PM, Paul Vixie <[email-masked]> wrote:
> no. it uses a DNS response message of rcode SERVFAIL for error signalling. so, it is as transparent as possible, and no more.

Okay.   So the upstream proxy is intended to simply take the "tcp" or "udp" indication and do the query using tcp or udp as indicated?   What if I write a proxy that doesn't support this behavior—will your downstream proxy fail to interoperate with it?   E.g., if it does the query using TCP, or automatically fails over to TCP if it gets a truncated response, and therefore returns a long response to a UDP query, will bad things happen?

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Apr 2018 22:11:29 +0100

Paul Vixie <[email-masked]> wrote:
> that would be low fidelity.

I'm interested to know what breaks with something like dnscrypt-proxy or
stubby that works with your proxy.

>From a quick look, I think your proxy doesn't handle AXFR and (more
generally) doesn't map client TCP connections onto server TCP connections,
so it doesn't allow a client to distinguish between servers that have
serial vs concurrent DNS-over-TCP request handling in a way that a truly
high-fidelity tunnel would.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Cromarty, Forth: North 5 to 7, occasionally gale 8 in Forth, becoming variable
3 or 4. Moderate or rough. Sleet, fair later. Good occasionally poor.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Apr 2018 14:45:36 +1000

> will not be influenced by middleboxes.

So don't include the middlebox in your communications.  It's all the
rage nowadays.