Re: [dnsoverhttp] Survey of DNS over HTTP

[Shane Kerr <[e-mail]>]

Stephen,

At 2016-09-15 08:28:11 +0100
Stephen Farrell <[e-mail]> wrote:

> 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)?

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

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

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

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

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

Cheers,

--
Shane