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 HTTP’s
> > > latency is almost the same as UDP.
> >
> > That's no
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 keep-alive cannot reduce late
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.
>
> That's not unexpected on a fast link,
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 i
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 in serialization latenc
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
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 things to
>fit into URL norms, or to use POST semantics where the block o
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": "
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
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 aest
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 man
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 rfc72
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. Righ
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
>fixed
>> before it goes forwards.
>>
>> - In the In
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 browsers. This is wrong,
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 que
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 and posted to the
> IETF r
17 matches
Mail list logo
