Subject: Re: [dnsoverhttp] [Ext] DNS over HTTP: next steps?

From: Zach Lym <[email-masked]>
Date: Thu, 5 Jan 2017 11:21:49 -0700

I worked at EasyDNS and worked on their REST API and tried building
something that could translate between APIs.  I'm now working on a JS DNS
polyfill.

I would love to see the early drafts of what people are thinking about, any
Github repos I could peak at?

Thank you,
-Zach Lym

On Fri, Dec 23, 2016 at 1:11 PM, Patrick McManus <[email-masked]>
wrote:

> First, I want to thank everyone for coming out to the bar bof and
> contributing their honest and positive energy. It was a good discussion.
>
> Personally, I didn't find the room to have a lot of agreement(yet) to
> build a unified approach to {tunneling, h2, lookup, and publish} - which is
> what I was hoping for. So I'm not sure I personally have an immediate next
> step - I do like Paul and Joe's draft https://www.ietf.org/id/draft-
> hoffman-dns-over-http-01.txt as a starting point but I remain unclear on
> whether there would be support in using that as the seed for a working
> group forming bof.
>
> Also, take a look at the minutes and you'll find some people (4-5)
> expressed interest in writing other drafts that could be the basis of a
> BoF. I would think it would be incumbent on those folks to step forward
> with at least their outlines. This list remains a fine place to do that
> imo. https://www.ietf.org/mail-archive/web/dnsoverhttp/
> current/msg00070.html
>
> Happy Holidays all.
>
> -Patrick
>
>
> _______________________________________________
> dnsoverhttp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsoverhttp
>
>

---

From: Shane Kerr <[email-masked]>
Date: Fri, 6 Jan 2017 11:05:22 +0100

Zach,

Well, there's Paul Hoffman's draft:

https://tools.ietf.org/html/draft-hoffman-dns-over-http-01

It describes how to make the query. I don't know if there are any
implementations, but it seems straightforward depending on what the
client wants to do.

For our DNS over HTTP work at BII Labs, which is basically tunneling DNS
over HTTP, we have a draft and a few GitHub repositories. The latest
draft, which is sort of in limbo until we figure out whether any
serious work will happen in this dnsoverhttp group:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/

Original C proxy version by Paul Vixie (not part of BII Labs):

https://github.com/BII-Lab/DNSoverHTTP

Go implementation by Runxia and myself (proof of concept, but works):

https://github.com/BII-Lab/DNSoverHTTPinGO

Plus a horrible hack in JavaScript that I put together at an IETF
Hackathon just to explore the idea:

https://github.com/shane-kerr/DNSoverHTTPinJavaScript

Apparently the demo is still running. :-P

http://blij.tk:8888/

Cheers,

--
Shane

At 2017-01-05 11:21:49 -0700

---

From: Erik Kline <[email-masked]>
Date: Sun, 8 Jan 2017 20:34:23 +0900

Shane,

Can you clarify something for me about the wireformat draft, section 3.4?

I believe that a client proxy does not include the DNS-over-TCP 2 byte
length toward the server, instead relying on the HTTP content-length.
Is it fair (and would be more clear) to simply say that the
DNS-over-TCP 2 byte length is *never* included when encapsulating over
HTTP regardless of role and query vs. response status?

I'm also a tad confused about how things look if one was, for example,
doing a zone transfer via DNS-over-HTTP and the server wanted to send
things with Transfer-Encoding of type chunked?

Actually, re-reading RFC 7230 sections 3.3.1 and 3.3.2, I believe that
if it's a requirement to include a Content-Length header then that
means Transfer-Encoding MUST NOT be used.  Is this fair to say, and is
it true of all DNS-over-HTTP data streams, regardless of role and
direction (i.e. it doesn't just apply to client requests)?

My apologies if I'm focusing on minutiae too early in the process.

Thanks.
-ek

---

From: Shane Kerr <[email-masked]>
Date: Tue, 17 Jan 2017 18:28:15 +0800

Erik,

Apologies for the late reply!

At 2017-01-08 20:34:23 +0900

> HTTP regardless of role and query vs. response status?

I think that's fair.

The basic idea is that you don't need any length indicator for the DNS
message because HTTP already includes that information.

However, I have re-written this section at least 3 times and every time
someone ends up finding it unclear in some way. :( I think that I might
not be able to write this in good way. Maybe someone can help?
 
> things with Transfer-Encoding of type chunked?

I haven't actually thought about it. Generally server-to-server
communications fall outside of the scope of the draft. I would expect
those to use normal DNS over TCP.

But in principle there is nothing to prevent a user from asking for a
zone transfer (I do it all the time, actually), and no reason why this
shouldn't work over HTTP.

> direction (i.e. it doesn't just apply to client requests)?

Thinking about it, I don't think there is a strong requirement to
include a Content-Length header. Honestly all that we really need is
for the data to end up on the other end, and to know how much got
there. Any transfer encoding should work for this.

Probably I should go through the document and remove references to
this, and make it more general to indicate this. Do you think it makes
sense to include Content-Length as an example of a possible way to do
this or would that confuse things?

> My apologies if I'm focusing on minutiae too early in the process.

Not at all! I'm not actually sure where this draft is process-wise. :)

Cheers,

--
Shane

---

From: Erik Kline <[email-masked]>
Date: Tue, 17 Jan 2017 23:00:10 +0900

> this or would that confuse things?

I suspect the thing to do is find the right way to refer to the right HTTP
transport text.  https://tools.ietf.org/html/rfc7230#section-3.3 and
subsections have thoughts on this.

So maybe, if this progresses, just:

    - never prefix a message with 2 byte lengths (a la DNS over TCP)
    - use whatever the HTTP transport wants to use
    - profit?

---

From: Patrick McManus <[email-masked]>
Date: Tue, 17 Jan 2017 15:45:35 -0500

>     - use whatever the HTTP transport wants to use

if that draft were to go forward I think that's right. Its the transport's
job to do the framing for you.. don't constrain it by referring to
content-length or chunking or you may find yourself incompatible with the
transport (which rather defeats the purpose of using HTTP). Even referring
to 7230 is over constraining, as 7540 (http/2) does things differently and
there's no reason to be incompatible with that.

focus on the definition of a media type, and let HTTP worry about the
transport and negotiation of alternate types (should they exist).