Re: [DNSOP] New draft for helping browsers use the DoH server associated with a resolver

Wouldn’t that be simpler to use SRV, and require no new RRTYPE? If a 
previously-granted resolver via DHCP was 192.168.1.1, then a lookup and 
result of:

  _doh._tcp.1.1.168.192.in-addr.arpa.  86400 IN SRV 10 60 443 
dns-doh.example.com.

  …would provide the client with a DOH resolver at 
“dhs-doh.example.com” after a subsequent and hopefully final non-DOH 
lookup on the name(s). Or multiple DOH resolvers could be returned, if 
one wished to use SRV expansion to its full extent.

  I know there are some leakage problems here in certain cases to 
upstream resolvers, and there is a serious fundamental problem with the 
first-query (bootstrap) trust chain in a practical sense, but the same 
issue exists with a new RR type and I suspect will be far longer to 
implement a new RR type than to use SRV which already exists. I see the 
risks as close to identical.

  “DOH” of course isn’t an official service name, but RFC2782 
allows for service names that are local, so maybe there is a task to get 
“doh” turned into an official service name but in the meantime it 
can work without official nomenclature. It’s entirely possible 
“doh” is already on track or listed as a service name and I’ve 
missed it, despite the fact that it is really just HTTPS, even though 
we’re overloading the service type, as seems to be the case for 
[everything]-over-HTTPS.  That seems thin as an objection.

  I’m probably overlooking an obvious reason that this isn’t a use 
case for SRV, but it’s been a long day in a different timezone than 
I’m used to. Slings and arrows welcome.

JT

On 23 Aug 2018, at 17:01, Paul Hoffman wrote:

> Greetings again. Some of the people in the recent thread about 
> "dynamic discovery of secure resolvers" have expressed an interest in 
> something that was mentioned at the DRIU BoF in Montréal: they want 
> their browser to use a DoH server that is related to the DNS resolver 
> that their OS is already using. I don't think DHCP can help with that 
> problem (I could be wrong), but I do think that resolver operators 
> should be able to tell browsers the DoH resolvers that they would want 
> their customers to be using.
>
> Please see the draft below. If folks like it, I can continue to work 
> on it. Or, if you like the use case but have a better technical 
> solution, that would be great too. I wanted to bring it to this list 
> before taking it to the DOH WG because it really is an operational 
> issue, not all that related to the DoH protocol.
>
> Thoughts?
>
> --Paul Hoffman
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> Title : Associating a DoH Server with a Resolver
> Author : Paul Hoffman
> Filename : draft-hoffman-resolver-associated-doh-00.txt
> Pages : 8
> Date : 2018-08-23
>
> Abstract:
> Some clients will want to know if there are one or more DoH servers
> associated with the DNS recursive resolver that the client is already
> using. This document describes a protocol for a resolver to tell a
> client what its associated DoH servers are.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hoffman-resolver-associated-doh/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-hoffman-resolver-associated-doh-00
> https://datatracker.ietf.org/doc/html/draft-hoffman-resolver-associated-doh-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/
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop