Subject: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt

From: Davey Song <[email-masked]>
Date: Thu, 22 Mar 2018 09:36:39 +0800

Hi folks,

I just submit a updated version of dns wireformat over HTTP. This draft has
been adopted as the dnsop wg document for quite a while before DOH.  The
original intention of this draft is to explore the possiblity of DNS over
HTTP(s) use cases and demonstrate its capacity as an experimental draft.
But the draft lacked enough specification on HTTP requirement and context
at that time. Since DOH later was setup focusing on developing https as DNS
transport protocol. So I updated this draft as a a special use case of DOH
which served as DNS proxy.

I would like to ask comments and advice in dnsop and doh wgs mainly two
quesions:
1) (for dns people) Does this proxy use case sounds useful as a IETF
experiment document .
2) (for HTTP people) Is a media type "application/dns-tcpwireformat"
acceptable specially for this use case. We also consider to introduce an
optional parameter to existing  "application/dns-udpwireformat" MIME in DOH
document, because the two media type carries the identical message body (the
udp dns wireformat)  in DOH request  in proxy use case. We need suggestion
here.

Thank to Tim and Paul Hoffman to bring this draft alive.

Davey

---------- Forwarded message ----------
From: <[email-masked]>
Date: 22 March 2018 at 08:59
Subject: New Version Notification for
draft-ietf-dnsop-dns-wireformat-http-02.txt
To: Shane Kerr <[email-masked]>, Paul Vixie <[email-masked]>,
Linjian Song <[email-masked]>

A new version of I-D, draft-ietf-dnsop-dns-wireformat-http-02.txt
has been successfully submitted by Linjian Song and posted to the
IETF repository.

Name:           draft-ietf-dnsop-dns-wireformat-http
Revision:       02
Title:          An Proxy Use Case of DNS over HTTPS
Document date:  2018-03-21
Group:          dnsop
Pages:          6
URL:            https://www.ietf.org/internet-drafts/draft-ietf-dnsop-dns-
wireformat-http-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-
wireformat-http/
Htmlized:       https://tools.ietf.org/html/draft-ietf-dnsop-dns-
wireformat-http-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-
wireformat-http
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-
wireformat-http-02

Abstract:
   This memo introduces a DNS proxy use case to tunnel DNS query and
   response over HTTPs using DOH, a newly proposed DNS transport.  This
   is useful in some situation where DNS is not working properly and DOH
   is not widely available for many stub-resolvers.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Richard Gibson <[email-masked]>
Date: Wed, 21 Mar 2018 22:14:42 -0400

I personally would rather see a single media type with a transport 
parameter than creation of a distinct media type for each transport 
(UDP, TCP, QUIC, …).

On 03/21/2018 09:36 PM, Davey Song wrote:
> Hi folks,
>
> I just submit a updated version of dns wireformat over HTTP. This 
> draft has been adopted as the dnsop wg document for quite a while 
> before DOH.  The original intention of this draft is to explore the 
> possiblity of DNS over HTTP(s) use cases and demonstrate its capacity 
> as an experimental draft. But the draft lacked enough specification on 
> HTTP requirement and context at that time. Since DOH later was setup 
> focusing on developing https as DNS transport protocol. So I updated 
> this draft as a a special use case of DOH which served as DNS proxy.
>
> I would like to ask comments and advice in dnsop and doh wgs mainly 
> two quesions:
> acceptable specially for this use case. We also consider to introduce 
> an optional parameter to existing "application/dns-udpwireformat" MIME 
> in DOH document, because the two media type carries the identical 
> message body (the udp dns wireformat) in DOH request  in proxy use 
> case. We need suggestion here.
>
> From: <[email-masked] <mailto:[email-masked]>>
> To: Shane Kerr <[email-masked] 
> <mailto:[email-masked]>>, Paul Vixie <[email-masked] 
> <mailto:[email-masked]>>, Linjian Song <[email-masked] 
> <mailto:[email-masked]>>
>
>
>
> URL: 
> https://www.ietf.org/internet-drafts/draft-ietf-dnsop-dns-wireformat-http-02.txt 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dietf-2Ddnsop-2Ddns-2Dwireformat-2Dhttp-2D02.txt&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=iL9ua2rpPYbCSUEq-K-R38UVlUtAtN8r1jwFWV5rSes&s=kcQHBMTTHWpQ0lbnTpgwMgxc1mJ3O30U7V-F4MgwwS8&e=>
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/ 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Ddnsop-2Ddns-2Dwireformat-2Dhttp_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=iL9ua2rpPYbCSUEq-K-R38UVlUtAtN8r1jwFWV5rSes&s=-ZiQiKWfvtNv-GvhxQZ4HkXEioo-dgD4OD0d64Wm7II&e=>
> Htmlized: 
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-http-02 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddnsop-2Ddns-2Dwireformat-2Dhttp-2D02&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=iL9ua2rpPYbCSUEq-K-R38UVlUtAtN8r1jwFWV5rSes&s=SxGZjmNNCjpRFZDAtVUc8JKtWzXWQgiwvDvFFSw-40Q&e=>
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-wireformat-http 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Ddnsop-2Ddns-2Dwireformat-2Dhttp&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=iL9ua2rpPYbCSUEq-K-R38UVlUtAtN8r1jwFWV5rSes&s=387hjMOuhZbHraMeqlq6MWaHbkQ4o8ssntxE3oXFjdI&e=>
> Diff: 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-wireformat-http-02 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Ddnsop-2Ddns-2Dwireformat-2Dhttp-2D02&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=iL9ua2rpPYbCSUEq-K-R38UVlUtAtN8r1jwFWV5rSes&s=h3RXu2GE1o3nFwNvDS6z1dwNFf-Gf9tdr4iSFsZ1FcU&e=>
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=iL9ua2rpPYbCSUEq-K-R38UVlUtAtN8r1jwFWV5rSes&s=PDgj6v2p23cDo2J86QRBXAec89h5izIPDxbUV3tS0nI&e=>.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=iL9ua2rpPYbCSUEq-K-R38UVlUtAtN8r1jwFWV5rSes&s=0vF3P6joSTSHJBQKI3cszqFLbofqMLOmmZwYOKjdAtw&e=

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 22 Mar 2018 06:23:42 -0400

Davey Song writes:
> Is a media type "application/dns-tcpwireformat" acceptable

Without yet having (re-)read the draft, I'm unclear on what benefit
this media type is bringing over dns-udpwireformat, since the only
difference presumably is explicitly adding the two octets of a
content-length <= 65535.  Is it something other than that?

---

From: Davey Song <[email-masked]>
Date: Thu, 22 Mar 2018 18:44:02 +0800

To keep the transparency of DOH proxy, the proxy server should use the same
transport as the proxy client receive queries from stub-resolver,
transports patterns like UDP-DOH-UDP, and TCP-DOH-TCP. So the proxy client
should signal the proxy server the initial transport recieve from
stub-client.

Davey

---

From: Bob Harold <[email-masked]>
Date: Thu, 22 Mar 2018 10:41:17 -0400

On Wed, Mar 21, 2018 at 9:36 PM, Davey Song <[email-masked]> wrote:

> Hi folks,
>
> I just submit a updated version of dns wireformat over HTTP. This draft
> has been adopted as the dnsop wg document for quite a while before DOH.
> The original intention of this draft is to explore the possiblity of DNS
> over HTTP(s) use cases and demonstrate its capacity as an experimental
> draft. But the draft lacked enough specification on HTTP requirement and
> context at that time. Since DOH later was setup focusing on developing
> https as DNS transport protocol. So I updated this draft as a a special use
> case of DOH which served as DNS proxy.
>
> optional parameter to existing  "application/dns-udpwireformat" MIME in
> DOH document, because the two media type carries the identical message body (the
> udp dns wireformat)  in DOH request  in proxy use case. We need
> suggestion here.
>
> Subject: New Version Notification for draft-ietf-dnsop-dns-
> wireformat-http-02.txt
> URL:            https://www.ietf.org/internet-
> drafts/draft-ietf-dnsop-dns-wireformat-http-02.txt
> Status:         https://datatracker.ietf.org/
> doc/draft-ietf-dnsop-dns-wireformat-http/
> Htmlized:       https://tools.ietf.org/html/d
> raft-ietf-dnsop-dns-wireformat-http-02
> Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-ietf-dnsop-dns-wireformat-http
> Diff:           https://www.ietf.org/rfcdiff?
> url2=draft-ietf-dnsop-dns-wireformat-http-02
>
> Abstract:

The first time "DOH" is used, it should be defined.  Either:
DOH (DNS over HTTP)
or:
DNS over HTTP (DOH)

I think the second is the preferred method.

-- 
Bob Harold

---

From: Davey Song <[email-masked]>
Date: Thu, 22 Mar 2018 14:55:38 +0000

Thanks for your advice.

Davey

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 22 Mar 2018 12:42:33 -0400

Davey Song writes:
> To keep the transparency of DOH proxy, the proxy server should use
> the same transport as the proxy client receive queries from
> stub-resolver, transports patterns like UDP-DOH-UDP, and
> TCP-DOH-TCP. So the proxy client should signal the proxy server the
> initial transport recieve from stub-client.

I'm really not digging this as a good use of a media type, especially
when the draft says:

  "If proxy client receives the query via TCP, then it
   will carry a new media type defined in this document "application/
   dns-tcpwireformat" and speak DOH with proxy server with the same
   DNS query without the two-byte length field defined in DNS over
   TCP"

So, dns-tcpwireformat and dns-udpwireformat are byte-for-byte
identical on the wire, and you're just using it as a signal for the
transport you want the DOH Proxy Server to use when talking to a
resolver (if indeed it is talking to separate resolver at all), is
that right?  If a transparent DOH proxy client is talking to a
co-operating DOH proxy server, shouldn't they have a better signaling
mechanism than that?  Is there any other media type that directs a
server on transport issues?

The use case also doesn't really address why it is important to
preserve the stub's udp-vs-tcp choice to its presumptive resolver, but
rather only refers only vaguely to the transparency issue.  It would
be nice to have a clearer statement of what's driving this proposal.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 22 Mar 2018 10:02:02 -0700

Dave Lawrence wrote:
> ...

nor i. apparently there were only worse choices, in the eyes of http folks.

> that right?

yes.

   If a transparent DOH proxy client is talking to a
> server on transport issues?

i had originally proposed an http query header to inform the far end as 
to what transport the near end had received the question on. this was 
seen as "not http-friendly". thus we have the proposal you now see.

> be nice to have a clearer statement of what's driving this proposal.

this is not a service, it's a proxy. that is, the far end should not 
start with udp (which is the usual dns initiator thing to do) and then 
make its own decision of whether to retry with tcp (for example on 
TC=1). the near end may already have tried udp and got TC=1. or the near 
end may have its own reasons for wanting to try tcp first.

if we were specifying a transport to a servive, like the DOH draft does, 
then we would not care about this. but this is a firewall bypass tool, 
not a dns-via-http service. thus, the near side of the proxy has to tell 
the far end of the proxy how we heard the query, so that it can use the 
same transport when it regenerates it for us on the far end.

-- 
P Vixie

---

From: Bob Harold <[email-masked]>
Date: Thu, 22 Mar 2018 13:04:41 -0400

> be nice to have a clearer statement of what's driving this proposal.
Unfortunately, the resolver needs to make decisions based on the original
transport, for example if the transport is TCP, it can send any size
response.  But if UDP, it needs to fit in a smaller size, and it often
sends less info in the response.  Likewise, session signalling,
anti-spoofing decisions, etc depend on the transport.

That brings up another question.  Would it also need to know the MTU of the
original connection, or any other info?  (Assuming EDNS is not used)  In
that case, a different media type is not enough, and we need to change the
format to add some 'header" info.

-- 
Bob Harold

---

From: Paul Vixie <[email-masked]>
Date: Thu, 22 Mar 2018 10:11:19 -0700

Bob Harold wrote:
>
> ...
>
> Unfortunately, the resolver needs to make decisions based on the
> original transport, for example if the transport is TCP, it can send any
> size response.  But if UDP, it needs to fit in a smaller size, and it
> often sends less info in the response.  Likewise, session signalling,

except that i don't find it unfortunately but simply factual, i agree.

>
> That brings up another question.  Would it also need to know the MTU of
> the original connection, or any other info?  (Assuming EDNS is not
> used)  In that case, a different media type is not enough, and we need
> to change the format to add some 'header" info.

not in my opinion. if the far end has a larger MTU outbound than the 
near end had inbound, then truncation damage will occur -- and the 
original initiator will retry with TCP. we just need to be transparent 
so that the original initiator can drive its own transport selections.

-- 
P Vixie

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Mar 2018 05:48:15 +0000

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

---

From: Paul Vixie <[email-masked]>
Date: Sun, 25 Mar 2018 23:08:32 -0700

Paul Hoffman 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:
>
> =====
>
> Optional parameters: original_transport original_transport has two
> defined values, "udp" and "tcp". This is only expected to be used by
> servers.

s/servers/proxies/

> This protocol does not define any use for the original_transport
> optional parameter of the application/dns-udpwireformat media type.
>
> =====
>

so this would look like

content-type: application/dns-udpwireformat; tcp

?

-- 
P Vixie

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Mar 2018 10:16:38 +0000

>> defined values, "udp" and "tcp". This is only expected to be used by

Maybe? I can't tell from the current draft if a proxy client would need to send a transport type.

> content-type: application/dns-udpwireformat; tcp

Not quite.
   content-type: application/dns-udpwireformat; original_transport=tcp

--Paul Hoffman

---

From: Davey Song <[email-masked]>
Date: Fri, 30 Mar 2018 16:53:01 +0800

Hi Paul,

It sounds reasonable as we discussed before.

Best regards,
Davey

On 26 March 2018 at 13:48, 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:
>
> =====
>
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Davey Song <[email-masked]>
Date: Fri, 30 Mar 2018 16:53:51 +0800

>    content-type: application/dns-udpwireformat; original_transport=tcp

Yes. That's right. I will give a example like that.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 31 Mar 2018 01:13:28 +0000

I have opened a pull request for this change:
   https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/127

--Paul Hoffman