Subject: Re: [DNSOP] I-D Action: draft-song-dns-wireformat-http-01.txt

From: Davey Song <[email-masked]>
Date: Wed, 2 Mar 2016 10:44:16 +0800

On Tue, Mar 1, 2016 at 11:58 AM, Paul Hoffman <[email-masked]> wrote:

> This document is a good idea, but it has some faults that need to be fixed
> before it goes forwards.
>
> - In the Introduction, it says in essence that this is just using HTTP to
> tunnel DNS and is not of use to web browsers. This is wrong, I believe.
> JavaScript in browsers cannot create port 53 queries, but they can create
> arbitrary HTTP/HTTPS queries. This protocol would allow JavaScript apps to
> get DNS responses as long as they could cobble together the request bytes
> and interpret the response. It would be ugly, yes, but so is a lot of stuff
> I see in JavaScript these days.
>
> If it is feasible (or there is an technical requirement) that JavaScript
can handle wire-format DNS massage over HTTP, it is no reason to exclude
it. So the simple way to edit this is to get rid of such saying of denying
web browser user.

> - Using POST for queries goes against the design of HTTP. POST is for
> requests that change state on the server, and DNS queries are not that.
> This protocol should use GET.
>
Fair enough.

>
> - The lack of a common URI template will completely prevent
> interoperability. You should instead use .well-known prefix for getting the
> syntax as described in RFC 5785.
>
I agree we should end up with a fixed URI template which can be recognized
by both client and server. Particularly in Proxy mode, the server proxy
will leverage the 80/443 port with existing Web server, we should avoid
conflicts with existing web service URIs.

- Section 3.3 is completely unclear. Either prohibit the two-byte length
> added for TCP queries, or require them all the time. Making them optional
> will make interoperability difficult or impossible.
>

What we say in Section 3.3 is not including the two-byte field in the
message sent to the server. Is the text not clear ? I will try to make it
more clear

>
> - Having no security considerations for a protocol that has optional HTTPS
> seems like a big oversight.
>
Yes. I admit it is a big oversight here. I will discuss with co-authors.
Any suggestions ?

>
> Hope this helps!
>
> Thank you ! The original  idea is to document how we implement the
software and try to share the communication pattern with other developers.
Now we should follow IETF way to formalized the document : )

Davey

> --Paul Hoffman

---

From: P Vixie <[email-masked]>
Date: Wed, 02 Mar 2016 03:08:56 +0000

We did not use get because get does not have a request payload.

On March 1, 2016 6:44:16 PM PST, Davey Song <[email-masked]> wrote:
>------------------------------------------------------------------------
>
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Davey Song <[email-masked]>
Date: Wed, 2 Mar 2016 18:04:41 +0800

According to RFC7231 (section 4.3.1), payload is not defined for GET and
GET request with payload will be reject by some implementation (like google app
engine) . It is not say GET should not use a request payload. the draft
actually propose a new payload definition for DNS over HTTP scenario. Right?

On Wed, Mar 2, 2016 at 11:08 AM, P Vixie <[email-masked]> wrote:

>>> This document is a good idea, but it has some faults that need to be
>>> fixed before it goes forwards.
>>>
>>> - In the Introduction, it says in essence that this is just using HTTP
>>> to tunnel DNS and is not of use to web browsers. This is wrong, I believe.
>> I agree we should end up with a fixed URI template which can be
>> recognized by both client and server. Particularly in Proxy mode, the
>> server proxy will leverage the 80/443 port with existing Web server, we
>> should avoid conflicts with existing web service URIs.
>>
>>> - Having no security considerations for a protocol that has optional
>>> HTTPS seems like a big oversight.
>>>
>> ------------------------------
>>
>> DNSOP mailing list
>> [email-masked]

---

From: Davey Song <[email-masked]>
Date: Wed, 2 Mar 2016 18:05:16 +0800

I found a discussion on HTTP GET with request body:
http://stackoverflow.com/questions/978061/http-get-with-request-body

Generally, it is not encouraged using GET with request body in this
conversation. It is said that rfc2616#section-4.3 recommends server toignore
undefined entity-body. But rfc7230#section3.3 did not recommend that server
behavior. another reason is library support varies on supporting GET with
payload.

For pure "Aesthetics" reason, If I was designing a toy protocol or a custom
tool, then I might insist on GET. but I should choose POST to work around
broken software and proxy in the networks.

On Wed, Mar 2, 2016 at 6:04 PM, Davey Song <[email-masked]> wrote:

>>>> If it is feasible (or there is an technical requirement) that
>>> JavaScript can handle wire-format DNS massage over HTTP, it is no reason to
>>> exclude it. So the simple way to edit this is to get rid of such saying of
>>> denying web browser user.
>>>
>>>

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 02 Mar 2016 07:00:50 -0800

> broken software and proxy in the networks.

Just to be clear: it's not just aesthetics. There are many other systems 
that make the assumptions about GET and POST.

We talked about this in Yokohama. Your design is "I want to put the 
message in the body" instead of "I can easily encode the request as a 
URL". If you want this protocol to be standardized in the IETF, you 
really should consider the decades of work that have gone into HTTP by a 
community much larger than the DNS community, and use that community's 
long-standardized semantics.

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Wed, 02 Mar 2016 08:36:28 -0800

> long-standardized semantics.

it is very common to use POST to transmit data in ways that do not 
change the state of the server. even in the most common "web forms" 
case, many web forms are lookups that only return information, rather 
than changing server state based on form data.

i do not believe that using POST will slow down standardization on this.

-- 
P Vixie

---

From: George Michaelson <[email-masked]>
Date: Thu, 3 Mar 2016 13:00:44 +1300

Bearing in mind that I like being a purist and could understand the
GET/POST thing in terms of architecture, I'm asking myself if it makes
sense to use GET URL semantics which require super-encoding things to
fit into URL norms, or to use POST semantics where the block of data
might be constrained by what we want to say, but the MIME encodings
are there to make it easier to say what it is, and why its encoded
that way.

I'd also ask myself: what to VPN's do, which use HTTPS as a transport?

I'm pretty sure they use POST. Happy to be proved wrong.

-G

On Thu, Mar 3, 2016 at 5:36 AM, Paul Vixie <[email-masked]> wrote:
> it is very common to use POST to transmit data in ways that do not change
> the state of the server. even in the most common "web forms" case, many web
> forms are lookups that only return information, rather than changing server
> state based on form data.
>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 02 Mar 2016 16:15:50 -0800

a web services version of dns-via-http(s) would use restful queries and 
json results. so,

GET http://util.redbarn.org/dns/v1/query/www.google.com/in/aaaa

{
   "rcode": "noerror",
   "question": [
     { "qname": "www.google.com", "qclass": "in", "qtype": "aaaa" }
   ],
   "answer": [
     { "name": "www.google.com",
       "class": "in",
       "type": "aaaa",
       "ttl": "154",
       rdata = [ "2607:f8b0:4005:802::2004" ]
     }
   ]
}

here, ancount/qdcount/nscount/adcount are expressed by the size of 
arrays, rrsets are slabbed, and empty sections are omitted. there are a 
million ways to do the json part. the restful part would need some kind 
of &opt= to express edns parameters, or just more positional parameters. 
you'd use POST for UPDATE and NOTIFY.

but that's a web services thing, which ought to exist, but which this 
proposal is not. this proposal is about taking binary DNS messages and 
slopping them around inside POST payloads and responses. you mentioned 
MIME but frankly my expectation is that it'll mostly be binary data 
since HTTP is 8-bit clean -- this isn't e-mail here.

the folks who think this proposal ought to use RESTful JSON are missing 
the point. this is not that. both should exist. but, this is not that.

paul

re:

George Michaelson wrote:
> On Thu, Mar 3, 2016 at 5:36 AM, Paul Vixie<[email-masked]>  wrote:
>>
>> Paul Hoffman wrote:

-- 
P Vixie

---

From: "John Levine" <[email-masked]>
Date: 3 Mar 2016 04:12:58 -0000

>are there to make it easier to say what it is, and why its encoded

I went back and looked at the http 1.1 spec, which says that GET is
idempotent and intended for reading stuff, PUT is not and intended for
writing stuff, and POST may or may not be and does whatever it does.

So POST to fetch data feels yucky, but I don't see it as so yucky as
to demand that they use GET with the query encoded into the URL path.

R's,
John

---

From: Davey Song <[email-masked]>
Date: Thu, 10 Mar 2016 17:15:12 +0800

FYI. A simple lab test done by my colleague.

http://www.dnsv6lab.net/2016/03/05/A-performance-test-of-DNS-over-different-transport-protocol/

There are some observations：

1) Keep-alive does reduce latency in long time queries. It is a little
surprising to see that with keep-alive, DNS over HTTP’s latency is almost
the same as UDP.
2) When coming to HTTPS, the keep-alive cannot reduce latency
significantly. The reason is probably that TLS has to do the handshake to
change the key which might be the main cost of latency.
3) HTTP/2 can reduce the latency in HTTPS.
4) For the first query, DNS over HTTP’s latency is nearly two times of UDP,
which is reasonable and a little bigger than TCP.
DNS over TLS’s latency is larger than DNS over HTTPS, even with keep-alive.

On Mon, Feb 29, 2016 at 4:13 PM, Song Linjian (Davey) <[email-masked]
> wrote:

> Hi Bob ,
>
> I update the draft to 01 version to respond to your suggestion and
> question.
>
>
> A new version of I-D, draft-song-dns-wireformat-http-01.txt
> has been successfully submitted by Linjian Song and posted to the
> IETF repository.
>
> Name: draft-song-dns-wireformat-http
> Revision: 01
> Title: DNS wire-format over HTTP
> Document date: 2016-02-29
> Group: Individual Submission
> Pages: 8
> URL:
> https://www.ietf.org/internet-drafts/draft-song-dns-wireformat-http-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/
> Htmlized:
> https://tools.ietf.org/html/draft-song-dns-wireformat-http-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-song-dns-wireformat-http-01
>
> Abstract:
>   This memo introduces a way to tunnel DNS data over HTTP.  This may be
>   useful in any situation where DNS is not working properly, such as
>   when there is middlebox misbehavior.
>
> Best regards,
> Davey
>
> 在 2016年2月20日，04:03，Bob Harold <[email-masked]> 写道：
>
>
> On Thu, Feb 18, 2016 at 6:00 AM, Song Linjian (Davey) <
> [email-masked]> wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>        Title           : DNS wire-format over HTTP
>>        Authors         : Linjian Song
>>                          Shane Kerr
>>                          Runxia Wan
>> Filename        : draft-song-dns-wireformat-http-00.txt
>> Pages           : 8
>> Date            : 2016-02-17
>>
>> Abstract:
>>   This memo introduces a way to tunnel DNS data over HTTP.  This may be
>>   useful in any situation where DNS is not working properly, such as
>>   when there is middlebox misbehavior.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-song-dns-wireformat-http-00
>>
>> Davey Song(宋林健)
>> BII Lab
>> [email-masked]
>> Some thoughts while reading  draft-song-dns-wireformat-http-00
>
> 1.  Introduction
> third paragraph
> "Finally, developers can choose HTTPS to provides data
>    integrity and privacy as well."
> "provides" should be "provide"
> Also, there should be two spaces before "Finally" to separate it from the
> previous sentence.
>
> 3.2.  Header Fields
> I am trying to understand why the recursive server would care whether the
> original query was UDP or TCP?  Would it be concerned about source address
> spoofing?
> If the stub resolver is talking http directly, without a proxy, should it
> put 'tcp' in this field?  That should be made clear.
> If the proxy server is running on a loopback address, would it make sense
> to say 'tcp' even if the actual request was 'udp', assuming that address
> spoofing is the concern, and would not happen with a loopback?
>
> 3.3.  Message Body
> end of second paragraph
> "In the
>    context of HTTP, there is content-length header filed [section 3.3.2
>    in RFC 7230 [RFC7230]]in which the field-value is the same with two
>    bytes length field in DNS over TCP."
> "filed" should be "field"
> Also, are you saying that the two bytes DNS length field should not be
> included in the http body?  It is not clear to me, I think we should say
> that explicitly.
>
> --
> Bob Harold
>
>
> Davey Song(宋林健)
> BII Lab
> [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Thu, 10 Mar 2016 11:21:59 +0000

> surprising to see that with keep-alive, DNS over HTTP’s latency is almost

That's not unexpected on a fast link, but it would be worth estimating the
difference in serialization latency on slow links.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth: North 4 or 5, becoming variable 3 or less. Slight or
moderate. Mainly fair. Good.

---

From: George Michaelson <[email-masked]>
Date: Thu, 10 Mar 2016 14:19:55 +0100

I expect that DNS over TLS and DNS over HTTP/2 are both going to get
to much the same place because the technology is driving to the same
place: get more of the query into the initial incoming packet so that
the first response has useful payload. Do you think the differences
are down to more than implementation variations? If there was an
innate difference in speed, thats materially interesting.

I would expect that any kept-alive transport has a cost for re-key,
which amortizes out over the specific query. If you had enough queries
in the pipe, it might not be much overhead against other costs.

(I'm not a cryptographer and I sometimes think I'm not much of a
network specialist either)

-G

---

From: Shane Kerr <[email-masked]>
Date: Thu, 10 Mar 2016 20:39:16 +0100

Tony,

At 2016-03-10 11:21:59 +0000

> difference in serialization latency on slow links.

Runxia did simulate latency on the link - each of the 3 columns
represents a different delay (0, 20 msec, and 200 msec).

Actually, with long delay the RTT dominates and HTTP with keepalive
looks most like UDP.

Cheers,

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Thu, 10 Mar 2016 20:47:19 +0100

All,

At 2016-03-10 17:15:12 +0800

> change the key which might be the main cost of latency.

It is an unfortunate thing is that TLS adds so much time.

My guess is that because of virtual hosting support in HTTP the TLS
session is re-negotiated for each query (using SNI), requiring
additional RTT.

I wonder if it might be possible for a library to cache the previously
used domain name and re-use a TLS session if it is the same? This could
provide a win in the general case, probably with a simple LRU
expiration to kick out TLS sessions and migrate to new ones if a new
domain name is being used.

This seems like the kind of thing that HTTP/2 folks would have already
thought of, but it doesn't look like the Go library implements this
sort of thing, just based on the performance measurements.

Cheers,

--
Shane

---

From: Tony Finch <[email-masked]>
Date: Thu, 10 Mar 2016 19:49:59 +0000

Shane Kerr <[email-masked]> wrote:
> > > 1) Keep-alive does reduce latency in long time queries. It is a
> > > little surprising to see that with keep-alive, DNS over HTTP’s
> > > latency is almost the same as UDP.
> >
> > That's not unexpected on a fast link, but it would be worth estimating
> > the difference in serialization latency on slow links.
>

I didn't mean link latency, I meant the latency due to the size of the
message, e.g. 2Kbytes at 56 Kbit/s is 300ms just to serialize the message
onto the wire.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Irish Sea: Variable 3 or 4, becoming south 4 or 5. Slight. Drizzle later.
Good, occasionally poor later.