Re: [dnsoverhttp] Survey of DNS over HTTP

[Stephen Farrell <[e-mail]>]

Hi Shane,

On 16/09/16 11:05, Shane Kerr wrote:
> 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. :) 

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.

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

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.

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

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.

> 
> Cheers,
> 
> --
> Shane
>