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) <songlinj...@gmail.com > 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 <rharo...@umich.edu> 写道： > > > On Thu, Feb 18, 2016 at 6:00 AM, Song Linjian (Davey) < > songlinj...@gmail.com> 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 >> songlinj...@gmail.com >> >> 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 > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > ------------------------------ > Davey Song(宋林健) > BII Lab > songlinj...@gmail.com > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
