Chrome's design attempts to use your current DNS settings to access a DoH resolver and fallsback to the current behaviour if it fails.
The browser isn't interfering in any of your network operations.
The browser isn't interfering in any of your network operations.
Sounds like interfering with the way my intranet operates to me.
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.
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 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.
The network is compromised. This is the fundamental assumption of networks. If you operate from this position you are much less likely to get burned.
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.
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?
(And yes, I set up a similar easy makeshift DNS solution to "authenticate" for the un-encrypted WLAN i had many years ago)