Subject: [dnsoverhttp] Survey of DNS over HTTP

From: Shane Kerr <[email-masked]>
Date: Wed, 14 Sep 2016 15:04:28 +0200

Hello,

I thought that people interested in this topic might find a draft
written by my colleagues and myself useful. It is a survey of various
DNS over HTTP techniques:

https://datatracker.ietf.org/doc/draft-shane-review-dns-over-http/

It needs to be updated, to reference Paul Hoffman's recent update to
his DNS JSON draft if nothing else:

https://tools.ietf.org/html/draft-hoffman-dns-in-json/

Cheers,

--
Shane

---

From: Patrick McManus <[email-masked]>
Date: Wed, 14 Sep 2016 11:29:05 -0400

Shane - Thank you. When I started researching what had been done in this
space I found that document to be one of the most interesting!

On Wed, Sep 14, 2016 at 9:04 AM, Shane Kerr <[email-masked]>
wrote:

> _______________________________________________
> dnsoverhttp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsoverhttp
>
>

---

From: George Michaelson <[email-masked]>
Date: Thu, 15 Sep 2016 08:19:50 +1000

And the update is work in progress? I hope so!

I think the document could usefully address the delay/cost thing you note.

Its worth quantifying. And, as we explore DTLS and different encodings
over HTTP/S, we're going to want a test base to make comparisons over.
I'd suggest a small dns label test set which can be used to verify
additional delay from a prepped cache (ie, remove the onward DNS
variant delay, and fetch solely from an entity which holds the
responses being sought)

Keep-alive? If the session is held open, the TCP establishment costs
are amortized. So, for comparison of DNS over TCP, DNS over HTTP may
have lower aggregate overhead in network protocol terms (obviously the
repeated encodings in the proto layers make this moot)

Nice doc.

_G

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 14 Sep 2016 21:56:40 -0400

I have to second (or third) this.  This is a really good review of DNS 
over HTTP.

Shane, since DNSOP was sort of 'meh' on adopting this work, perhaps an 
ISE would work?

I am also thinking some of this may end up in the document we have 
adopted (currently 
https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/)

tim

On 9/14/16 11:29 AM, Patrick McManus wrote:
> On Wed, Sep 14, 2016 at 9:04 AM, Shane Kerr <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hello,
>
>     <https://datatracker.ietf.org/doc/draft-shane-review-dns-over-http/>
>
>     <https://tools.ietf.org/html/draft-hoffman-dns-in-json/>
>
>     Cheers,
>
>     --
>     Shane
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dnsoverhttp>
>
>
>
>

---

From: George Michaelson <[email-masked]>
Date: Thu, 15 Sep 2016 12:18:47 +1000

The wire format draft is about wire format. This draft reviews other
methods. It feels to me like we need both: a wire format draft which
presents a canonical, complete mapping of DNS protocol to a wire
format encoded for transport over HTTP/S, and a review of the
alternates which people may situationally find themselves using, which
do not adopt that direct wire format method.

If we're heading to 'there can only be one' I think thats too early IMHO

-G

On Thu, Sep 15, 2016 at 11:56 AM, Tim Wicinski <[email-masked]> wrote:
>
> I have to second (or third) this.  This is a really good review of DNS over
> HTTP.
>
> Shane, since DNSOP was sort of 'meh' on adopting this work, perhaps an ISE
> would work?
>
> I am also thinking some of this may end up in the document we have adopted
> (currently https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/)
>
> tim
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Sep 2016 08:28:11 +0100

Hi Shane,

I have two related questions for which I didn't get answers
from your fine document.

1) Are folks using IP addresses or DNS names in the URLs they
are de-referencing when using HTTP(S)?

2) Are there any functional reasons to ever specifically want
DNS/HTTP, as opposed to DNS/HTTP/TLS? By functional I mean to
exclude the obvious simplicity, performance and WebPKI-trust
reasons why HTTP is "easier" than HTTP/TLS.

BTW, the reason these are related is that if folks are using
IP addresses for the requests, then our current inability to
get WebPKI certs for IP addresses may be a functional motivation
for preserving the ability to do DNS/HTTP in clear.

From my POV it'd be a bit sad if we need to define yet another
open-kimono/insecure way to do DNS, so I'd be happier were it
safe to assume that the client can use a DNS name in the URL
and can somehow figure out how to resolve that name to an IP
address. But I don't know if that's a reasonable assumption.

Cheers,
S.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 15 Sep 2016 14:59:57 -0700

Hi Shane,

Thanks for the doc.  One approach to add is using dns URIs as the target of
HTTP methods, returning the dns data using the relevant mime type.  In that
approach, you send the message over HTTP(S) with something like

GET  dns:[//authority/]domain[?CLASS=class;TYPE=type]

(See RFC 4501 for the full set of permitted syntax for DNS URIs)

and return either application/dns or text/dns records for the result (See
RFC 4027 for the specification of the MIME types).

This treats the server to whom you are speaking as it if were an HTTP
intermediary acting like a proxy, under a loose reading of RFC 7230's
description:

   A "proxy" is a message-forwarding agent that is selected by the
   client, usually via local configuration rules, to receive requests
   for some type(s) of absolute URI and attempt to satisfy those
   requests via translation through the HTTP interface.

In this case the type of absolute URI is a DNS URI.

regards,

Ted

---

From: Shane Kerr <[email-masked]>
Date: Fri, 16 Sep 2016 12:05:20 +0200

Stephen,

At 2016-09-15 08:28:11 +0100

> are de-referencing when using HTTP(S)?

I assume both.

Using DNS names does create a bootstrapping problem, but not a huge
one. After all, current DNS resolvers have a similar bootstrapping
problem when they start. They use a pre-configured set of IP addresses
to start (usually hints.txt) and perform resolver priming:

https://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-09

A client using DNS-over-HTTP can either use a pre-configured set of IP
addresses, or use some other way to map a DNS name into a set of IP
addresses - such as "normal" DNS. :) 

> reasons why HTTP is "easier" than HTTP/TLS.

By "functional reasons", you mean is there anything that DNS over HTTP
can do that DNS over HTTP+TLS can do? The only specific issue that I
can think of is virtual servers and client-side software that doesn't
support SNI. (Not as crazy at it seems... SNI was only added to
the standard Python TLS library in 2014 for example.)
 
> for preserving the ability to do DNS/HTTP in clear.

I'm not sure about this. (No, really, I am ignorant!)

RFC 3779 defines X.509 extensions for IP addresses, which is used by
RPKI:

https://tools.ietf.org/html/rfc3779

Also, a quick scan through RFC 5280 indicates that IP addresses can
also be used in web PKI:

https://tools.ietf.org/html/rfc5280#section-4.2.1.6

So it seems possible in principle to use IP addresses in certificates
with current standards.

In general though I'd expect DNS over HTTP clients to use a
pre-configured certificate from the resolver operator... sort of like
when you sign up for a VPN, and you get a certificate to identify the
server that you then configure on the client side. 
 
> address. But I don't know if that's a reasonable assumption.

I think that I understand your concern about unencrypted traffic, but
I'm not sure that insisting on it will actually help.

Cheers,

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Fri, 16 Sep 2016 12:09:58 +0200

Ted,

At 2016-09-15 14:59:57 -0700

> RFC 4027 for the specification of the MIME types).

I'm not sure that I understand the syntax. Can you give some examples?
 
Cheers,

--
Shane

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Sep 2016 12:48:21 +0100

Hi Shane,

> addresses - such as "normal" DNS. :) 

Interesting. So yeah, I'd guess that building in some such
priming would be useful for any DNS/HTTP thing. If we're
assuming that a major motivator for DNS/HTTP is that today's
DNS is sometimes problematic, then I guess one might have
more to say about how long a client depends on the results
of priming, whether that be based on DNS TTLs or something
else in addition.

> So it seems possible in principle to use IP addresses in certificates

Yep, entirely possible in principle, but I don't know of a
service where I can easily go get such a certificate. (If
someone does, I'd be interested). I think it's definitely
the case that server deployment will be a lot easier if
based on certs for DNS names.

> I'm not sure that insisting on it will actually help.

I was less thinking of insisting, and more of just not
explicitly defining a way to do it on port 80 at all:-)
But sure, it's not clear if that'd be acceptable as a
good plan in all cases.

Cheers,
S.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Sep 2016 09:02:15 -0700

> I'm not sure about this. (No, really, I am ignorant!)

As a practical matter, I don't see IP subjectAltName ever being used.
Better to retain the notion of a name, even if you don't use that name
in the process of establishing a connection to the server.

---

From: Patrick McManus <[email-masked]>
Date: Fri, 16 Sep 2016 12:16:00 -0400

> in the process of establishing a connection to the server.

I'd agree with that. Names can be useful for authentication without needing
to even loosely be bound to the addressing - especially for bootstrap..
this is an established mode of operation for far more than bootstrap - e.g.
CONNECT tunnels through a hardcoded proxy.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Sep 2016 09:17:12 -0700

> I'm not sure that I understand the syntax. Can you give some examples?

Ted is suggesting that you could construct a URI that entirely
encapsulated a DNS request.  I'm not certain that that is possible,
but it would be one way of constructing a protocol.

For instance, a MX request might be formulated by sending a GET to
dns:IN:MX:time-traveler.org

(Personally, I'm inclined to drop IN from the protocol, but that's just me.)

---

From: Ted Hardie <[email-masked]>
Date: Fri, 16 Sep 2016 09:25:29 -0700

> Sure.

GET dns:example.com?TYPE=AAAA

Would ask for the AAAA record for example.com, using whatever means the
HTTP server had for supplying the record.

GET dns://8.8.8.8/example.com?TYPE=AAAA

Would ask the server to consult 8.8.8.8 and return the AAAA record it
supplied.

(The URI scheme specified in RFC 4501 allows you to specify a CLASS, but
defaults to IN, which is why it's not supplied in the examples).

You can also use URI escaping to reference IDNs:

GET dns:www.example.%E4%B8%AD%E5%9C%8B?TYPE=TEXT

regards,

Ted

---

From: Ted Hardie <[email-masked]>
Date: Fri, 16 Sep 2016 09:29:17 -0700

Howdy,

> dns:IN:MX:time-traveler.org
In the syntax of RFC 4501, this would dns:time-traveler.org?CLASS=IN;TYPE=MX

> (Personally, I'm inclined to drop IN from the protocol, but that's just

It's a default in RFC 4501, so it doesn't need to be included:

dns:time-traveler.org?TYPE=MX

is equivalent.

There are some obscure bits of the DNS protocol you can't express in the
DNS URI scheme and return application/dns or text/dns, but it covers the
common ground pretty simply.

Ted

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Sep 2016 16:40:00 +0000

> but it would be one way of constructing a protocol.

FWIW, Joe Hildebrand and I have an almost-ready-to-publish draft doing exactly that. We're still hammering out bits on discovery and so on, but we should have it Real Soon Now.

--Paul Hoffman

---

From: william manning <[email-masked]>
Date: Fri, 16 Sep 2016 11:24:51 -0700

On Friday, 16 September 2016, Patrick McManus <[email-masked]> wrote:

>
> On Fri, Sep 16, 2016 at 12:02 PM, Martin Thomson <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> I'd agree with that. Names can be useful for authentication without
> needing to even loosely be bound to the addressing - especially for
> bootstrap.. this is an established mode of operation for far more than
> bootstrap - e.g. CONNECT tunnels through a hardcoded proxy.
>
>
Then you run into the problem where the machine owner has given it a name
and the DNS admin has given it a different name.  Inevitably the cert will
not be tied to the DNS name.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Sep 2016 13:45:32 -0700

> not be tied to the DNS name.

That's the joy of the security model, it doesn't matter what DNS says
(DANE excepted perhaps).  Only what is authenticated matters.

---

From: william manning <[email-masked]>
Date: Sat, 17 Sep 2016 07:18:46 -0700