Re: [Doh] Fallback to untrusted DOH servers

[Ted Lemon <[e-mail]>]

On Apr 14, 2018, at 9:36 AM, Mateusz Jończyk <[e-mail]> wrote:
> It may happen that either no trustworthy DOH server has been configured, or the
> configured DOH server is not working. In such cases a DOH client would usually
> revert to using an untrusted DNS server on port 53, possibly one that was
> discovered through unsecure DHCP. This DNS resolver would also be able to poison
> DNS caches then.
> 
> I think that in this case it would be better to use whatever DOH server is
> available as an alternative to an even worse old-school DNS. To avoid cache
> poisoning attacks, the client would then have to drop DNS caches after switching
> to a more trustworthy DNS once it has been configured or is available.

What threat model do you want to address?   Two things spring to mind as things you might care about:
"do I trust the DNS server"
"is the connection to the DNS server private?"

If the resolver was configured with keying information that can be validated as part of making the connection to the server, then you trust the server.   What exactly that means is a question in itself, but let's take that for granted for now.

In the case of DOH-I-don't-know versus DNS-I-don't-know, you don't have (1), so it doesn't matter which one you use, except that if you use some method other than DHCP to get to the DOH server, potentially what you have reached is even _less_ trustworthy than the DNS server.   So you could as easily be worse off as better off.

What you do get with DOH-I-don't-know as compared to DNS-I-don't-know is (2), for some value of "private."

So what threats does preferring DOH protect you from?   What threats _doesn't_ it protect you from?   What vulnerabilities does it create?   I think you need to answer all three of these questions if you're going to make the case that untrusted DOH should be preferred over untrusted DNS.

Your question about the local resolver is interesting.   I think what it points to, though, is that what DOH does is to solve a very different problem than the problem you are trying to solve with it.

If you want to solve the problem you are proposing to solve, the place it needs to be solved is in the local stub resolver implementation.   This is something we've seen before, and there's even an RFC that talks about it, RFC7556.   From the perspective of RFC7556, your "trusted" DOH resolver represents a provisioning domain, and it's the domain in which you would prefer to look up names.   Your local DNS resolver represents another provisioning domain.   

Provisioning domain DNS caches must be separate, to avoid cache poisoning.   You might have a whitelist of domains that can be looked up using the local resolver, and all other domains are just not available if the trusted DOH server isn't present.   Or you could have a blacklist of domains that are only sent to the trusted DOH server, and other domains can go either way.   Or some other security policy.