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

[Paul Hoffman <[e-mail]>]

On Aug 23, 2018, at 6:29 PM, John Todd <[e-mail]> wrote:
> 
> 
> 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 don't think this works for two orthogonal reasons:

- The browser doesn't necessarily know that address of the recursive resolver, just how to send queries to the recursive resolver through the OS's stub resolver

- Recursive resolvers don't all have control of their reverse address mappings in in-addr.arpa.

Even if both of those are fixed, it will yield less secure results because in-addr.arpa is not signed in DNSSEC, so attackers in the middle will always be able to change the responses (as compared to only being able to some of the time with the RAD RRtype I proposed).

> 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

Fully agree

> and I suspect will be far longer to implement a new RR type than to use SRV which already exists.

This doesn't seem to as daunting to me. On the client side, if a browser has a DoH client, it already has a full DNS stack, so adding in the requirement to be able to ask for RRtype TBD seems trivial. On the resolver side, it needs to have generic capture code to look for ./IN/RAD, and resolvers already have much more complicated code in them.

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

Hopefully the above is neither slings nor arrows!

--Paul Hoffman