So, assuming my local LAN DNS resolver, which serves my own custom DNS information to LAN clients, doesn't support DoH itself, but uses DoH to reach out to the authoritative servers, chrome will bypass this my local resolver?
Sounds like interfering with the way my intranet operates to me.
Chrome doesn’t know that your local intranet is trusted or that the local resolver is trustworthy. You need to tell Chrome this by flipping a switch to either change your DoH provider or disable it all together.
This change is explicitly protecting users from malicious network operators. Since you control the endpoints it should be no big deal, you apply GPO, run Puppet, whatever and everybody is talking to your local DNS again but it is absolutely right to not trust local unencrypted DNS by default for every network you connect to.
In that context, I'd be perfectly happy if chrome had a "I'm on an untrusted network right now" switch, like incognito window. Not sure we should assume that the entire network between the browser and cloudflare is untrusted though.
Aren't there some "hijacks" that are actually valuable to users? For example, if I run a network inside an extremely limited internet environment, I can hijack the user's DNS and redirect them to a "Hey, we're sorry, but running Netflix here will ruin the network for everyone, we hope you understand" page. If their browser is ignoring my local DNS server my option would seem to be simply black-hole netflix packets in the firewall, which is a lot less friendly to the user. Would I be a malicious network operator in this case?
There's presumably no way to allow that without also thereby allowing you to change the apparent content of the Netflix service—or of other sites! (Suppose that you could hijack the user's DNS to redirect ubuntu.com to a page that said "Thanks for your interest in Ubuntu! To download the latest version, click <a href='https://evil.com/ubuntu/ubuntu.iso'>here</a>." How can you allow one kind of hijacking without also allowing the other?)
There has been work on allowing networks to communicate out-of-band to browsers for administrative purposes. Even this is risky in general because of the phishing possibilities, among other things. Showing users arbitrary messages from network operators in the middle of the users' other browsing activities is likely to make it even easier to confuse the users into taking actions that they really didn't intend to do.
> Not sure we should assume that the entire network between the browser and cloudflare is untrusted though.
There's a strong case to be made that the vast majority of Chrome users aren't equipped to evaluate this question. These users are very unlikely to know if they're on an untrusted network and thus unable to make use of the kind of very useful switch you wisely suggest.
Perhaps offering a configuration option for the small percentage of technically sophisticated users who are willing to look in settings for it? Certainly Chrome Enterprise (which is a configuration management system, not a pay-for enterprise software offering) offers strong settings management tools.
Strictly from a security perspective, you always assume your network is untrusted and untrustworthy (and use protocols designed to work just fine in such situations). Especially when serving users who aren't equipped to make their own educated decisions. Can you help me understand why Chrome might want to behave otherwise?
Yes. You would be malicious. Doesn't matter what your intentions are if someone with bad intensions could do something bad in that scenario.
For example redirecting the user to a fake webpage asking for their username and password.
A user will learn that there's blocking if they try and access Netflix and it doesn't work.
You can get something like a Juniper SRX firewall which can recognise applications via signature and do blocking that way. Rather than against IP ranges only.
Also as a network admin you're not saying why you won't be able to block DNS over HTTPS providers.
Unless you're thinking there's going to be some unknown DNS server used by the browser.
But if that's your fear you'll need to block all the online DNS lookup websites.
What if a user just types the IP address directly? Totally circumnavigates DNS.
My problem with your "solution" is that it only works under very narrow assumptions. E.g. how does the Netflix client handle such a redirect? At best with "bad connection", I'd presume. I'd hope they would at least forward a better message when using a proper standard to do the blocking, if they consider this worth the effort.
(And yes, I set up a similar easy makeshift DNS solution to "authenticate" for the un-encrypted WLAN i had many years ago)
Why can't your local LAN DNS resolver support DoH itself if it can act as a DoH client to authoritative servers? That way the browser would know it can trust it to begin with.
The browser isn't interfering in any of your network operations.