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

From: "Song Linjian (Davey)" <[email-masked]>
Date: Thu, 18 Feb 2016 19:00:04 +0800

Dear DNSOP colleagues, 

I just submitted a draft on  DNS over HTTP.  Thanks for valuable comments and discussion around this topic months ago. I will appreciate if anyone can help review this draft.

If WG Chairs think this draft is in the scope of DNSOP, I will change the name with a DNSOP label afterwards.

Btw, last week it was celebrated for  Chinese New year, Monkey Year. I wish everyone best in the Chinese new year!

Best regards,
Davey 

> 下面是被转发的邮件：
> 
> 发件人: [email-masked]
> 主题: I-D Action: draft-song-dns-wireformat-http-00.txt
> 日期: 2016年2月18日 GMT+8 11:40:13
> 收件人: <[email-masked]>
> 回复－收件人: [email-masked]
> 
> 
> 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
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------------------------------
Davey Song(宋林健)
BII Lab
[email-masked]

---

From: Bob Harold <[email-masked]>
Date: Fri, 19 Feb 2016 15:03:36 -0500

On Thu, Feb 18, 2016 at 6:00 AM, Song Linjian (Davey) <[email-masked]
> wrote:

> 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

---

From: Davey Song <[email-masked]>
Date: Mon, 22 Feb 2016 17:35:44 +0800

Thanks for Typo fix suggestion. I have some explanation inline to your
questions

> spoofing is the concern, and would not happen with a loopback?

As the draft says, the Proxy-DNS-Transport header field used in proxy
configuration
in scenario 2 which help make the proxy transparent
to the UDP/TCP transport. The proxy can help to maintain all the features
TCP brings including source address spoofing.  If stub resolver is talking
http directly, there is not such field. client/server proxy may located in
different servers from stub client and the far-end recursive server. So
client/server proxy server can speak udp or tcp with them.

3.3.  Message Body
> included in the http body?  It is not clear to me, I think we should say

Yes, you are right. I should make it clear how to deal with the two-byte
length field for TCP DNS massage. Generally, there are two choices to
handle this. One is using HTTP header to wrap DNS massage with the two-byte
length field when client proxy receive TCP DNS packet. Another approach is
contain DNS massage without the two-byte length field and recalculate it
when server proxy compose a new TCP DNS query packet.  Both two approaches
can work, but client proxy and server proxy should use the same approach to
speak to each other. In the implementation we use the latter one.

Davey

--

---

From: "Song Linjian (Davey)" <[email-masked]>
Date: Mon, 29 Feb 2016 16:13:22 +0800

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 <https://www.ietf.org/internet-drafts/draft-song-dns-wireformat-http-01.txt>
Status:         https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/ <https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/>
Htmlized:       https://tools.ietf.org/html/draft-song-dns-wireformat-http-01 <https://tools.ietf.org/html/draft-song-dns-wireformat-http-01>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-song-dns-wireformat-http-01 <https://www.ietf.org/rfcdiff?url2=draft-song-dns-wireformat-http-01>

Abstract:

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] <mailto:[email-masked]>> wrote:
>> https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/ <https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/>
>> 
>> https://tools.ietf.org/html/draft-song-dns-wireformat-http-00 <https://tools.ietf.org/html/draft-song-dns-wireformat-http-00>
>> 
> 
> [email-masked] <mailto:[email-masked]>
> 
> 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
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Bob Harold <[email-masked]>
Date: Mon, 29 Feb 2016 09:33:32 -0500

On Mon, Feb 29, 2016 at 3:13 AM, Song Linjian (Davey) <[email-masked]

> URL:
> https://www.ietf.org/internet-drafts/draft-song-dns-wireformat-http-01.txt
> Status:
> 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:
> On Thu, Feb 18, 2016 at 6:00 AM, Song Linjian (Davey) <
> [email-masked]> wrote:
>
> 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

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 29 Feb 2016 19:58:44 -0800

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.

- 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.

- 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.

- 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.

- Having no security considerations for a protocol that has optional 
HTTPS seems like a big oversight.

Hope this helps!

--Paul Hoffman