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

Shane Kerr wrote: > At 2016-03-10 11:21:59 + > Tony Finch wrote: > > > Davey Song wrote: > > > > > > 1) Keep-alive does reduce latency in long time queries. It is a > > > little surprising to see that with keep-alive, DNS over

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

All, At 2016-03-10 17:15:12 +0800 Davey Song wrote: > 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： > 2) When coming to HTTPS, the

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

Tony, At 2016-03-10 11:21:59 + Tony Finch wrote: > Davey Song 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. >

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

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

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

Davey Song 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

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

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

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

In article you write: >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

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

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/ { "rcode": "noerror", "question": [ { "qname": "www.google.com", "qclass": "in", "qtype": "" } ], "answer": [ { "name":

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

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

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

Paul Hoffman wrote: On 2 Mar 2016, at 2:05, Davey Song wrote: 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. Just to be clear: it's not just

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

On 2 Mar 2016, at 2:05, Davey Song wrote: 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. Just to be clear: it's not just aesthetics. There are

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

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

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

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.

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

We did not use get because get does not have a request payload. On March 1, 2016 6:44:16 PM PST, Davey Song wrote: >On Tue, Mar 1, 2016 at 11:58 AM, Paul Hoffman >wrote: > >> This document is a good idea, but it has some faults that need to be

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

On Tue, Mar 1, 2016 at 11:58 AM, Paul Hoffman 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

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

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

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

On Mon, Feb 29, 2016 at 3:13 AM, Song Linjian (Davey) 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

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

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: