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

[Paul Hoffman <[e-mail]>]

On Aug 24, 2018, at 6:43 AM, Vladimír Čunát <[e-mail]> wrote:
> 
> On 08/24/2018 02:01 AM, Paul Hoffman wrote:
>> Thoughts?
> 
> Well, if the OS resolver is validating, it will SERVFAIL with such a
> query.  

The protocol requires special handling of those specific queries, so a resolver that understands the protocol will give the desired answer. A resolver that doesn't understand the answer will give NXDOMAIN even if it is validating because that RRtype is not in the root zone.

> Furthermore, if it uses aggressive caching, it may even give a
> negative reply without asking upstream that would answer positively. 

...which is fine for resolvers that do not know the protocol.

> That is, unless the RFC instructs forwarding resolvers to do otherwise,
> but that would seem a nasty special case for little benefit.

Forwarding resolvers do not need special casing, I believe. If the forwarding resolver understands the protocol, it will reply. If it doesn't understand the protocol, it will forward and give back whatever the upstream resolver tells it. 

> I assume the non-validation is a conscious tradeoff, as such resolvers
> seem not a common OS default, and they're more likely to support DoT or
> DoH anyway, hopefully reducing the need for browsers to roll their own.

I admit I had not considered validating stub resolvers. Now that you bring it up, a validating stub resolver will get an answer that cannot be validated, and thus will mark it Bogus. This feels like a limitation, but one that can't really be worked around unless we use a RFC 6761 TLD that is guaranteed to be unsigned.

> I'm not sure I understand the motivation for the stated use case, but
> apparently others perceive it as useful...

Restating the motivation: a browser that wants to use DoH might also want to let the user say "I trust the DoH server that my configured resolver is associated with". That eliminates the need to have DHCP know which DoH servers are associated with the Do53 servers that it is announcing, and it also eliminates the need for the OS to know about those DHCP updates.

Hopefully this helps. But thank you for bringing up the validating stub issue.

--Paul Hoffman