On Mon, Feb 29, 2016 at 3:13 AM, 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 > > > That is an improvement. Some further comments: 2. Methodology and Configuration -- last sentence: "is is acting as a proxy server." "is is" should be "it is" 3.2. Header Fields -- last sentence contains: "then this flag is not necessary" Are you saying the flag can be missing? I think we should rather say: "then the flag should be set to TCP" Or specify no flag: "then this flag should not be included. If the flag is not included, this indicates that the client is using http(s) directly, and should be treated the same as a TCP connection." But always setting the flag seems simpler to me. -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
