Re: [Doh] [Ext] Associating a DoH server with a resolver

[Paul Hoffman <[e-mail]>]

Sorry for the belated reply to this. Gotta love corporate mail systems...


On Oct 23, 2018, at 2:05 PM, Ben Schwartz <bemasc=[e-mail]> wrote:
> 
> Hi Paul, thanks for the continuing work on this topic.
> 
> Two related questions:
> 1. Does the resolver have to return its own IP in the RR for resolver-addresses.arpa, or can it return some other IP addresses?

The current wording is that the resolver returns its own IP address, which makes the resolver operator responsible for running the service that will respond to the well-known URI. There is no expectation that the URI templates returned from the well-known URI will all point to that same resolver; it would be find for the resolver operator to point to trusted third-party services.

> 2. If a client has some OS-specific way to enumerate the DNS server IPs for the default network interface, is it still required to perform "Step 1"?  (Most OSes do have some enumeration mechanism like this.)

Good point; I'll add this to the next draft and say "no". I'll also say "if the application can enumerate the OS's preferred DoH servers, there is no need to use the protocol here at all".

> Other minor comments:
> On Section 4, User Interface: I don't see the need for a user interface here.  In my view, opportunistic security generally shouldn't require user action and shouldn't produce a user-visible change.

Browser vendors might prefer that, privacy-concerned users might want a UI. I guess I'm targeting the latter.

> I think interaction with DoT is worth discussing here, even though it's probably trivial.  If I can probe for DoT and (with this draft) DoH, which one do I probe first, and which should I prefer if both succeed?

Yes, I'll add a stub for discussion of this.

--Paul Hoffman