Except when the client ignores what you tell it. Per Paul Vixie:
google, this is bogus as hell. my dhcp server gives you dns servers to
use. please don't make me route and answer 8.8.8.8 just to watch youtube.
> [71] 2019-02-13 16:39:40.548137 [#68 vtnet0 4095] \
> [24.104.150.186].56915 [8.8.8.8].53 \
> dns QUERY,NOERROR,7357,rd \
> 1 lh3.googleusercontent.com,IN,A 0 0 0
> [71] 2019-02-13 16:39:40.548210 [#69 vtnet0 4095] \
> [24.104.150.186].56915 [8.8.8.8].53 \
> dns QUERY,NOERROR,49247,rd \
> 1 lh3.googleusercontent.com,IN,AAAA 0 0 0
(no, this device i've paid for, will NOT be allowed to send you any
information, other than what i personally approve, which will never
include DNS traffic. if you don't like that deal, buy it back from me
and i'll find some other video appliance that doesn't twist my arm.)
Of course with DoH you can't just do a UDP redirect. With DoT, which uses tcp/953, you can at least block access.
But with DoH, you have just lost control of your network. (Unless block 443 and force everything to go through a (Squid) proxy?)
If you can't trust your device, you can't trust it without DoH either. As I said upthread, devices don't even need to use DNS. They can open up encrypted C&C channels, using whatever protocol they'd like, tunneled over whatever they'd like. They can bake rendezvous IP addresses in, they can cryptographically verify endpoints to break MITM proxies, they can even sneak data out in ICMP packets. DoH has literally nothing to do with it.
What's insidious about this argument is that it preys on peoples legitimate concerns about uncontrolled devices on their network. We're all concerned about that! But that doesn't mean we should use plaintext DNS, or Paul Vixie's preferred "encrypted DNS with a killswitch for network operators".
Might as well argue against using windmills to grind wheat.
Sometimes you don't choose the software, the software chooses you:
* https://www.zdnet.com/article/first-ever-malware-strain-spot...
* https://www.zdnet.com/article/psixbot-malware-upgraded-with-...
I'm happy to implement DoT on work's network to help encourage encrypted DNS. My problem is DoH can now be used by all sorts garbage and we can't tell it from legitimate HTTPS--which is by design.
All this for the laudable goal of protecting Internet surfers' privacy. However I'm curious to know how well this will work against the Great Firewall of China, and how many other regimes will now implement Great Firewalls of their own.
Malware can ship with an arbitrary number of DNS-over-HTTPS servers accessible anyway, no matter whether Google supports it. The cat was out of the bag as soon as you allowed encryption on your network in general.
Finally, there are system architectures that are inherently less susceptible to malware, which is what we should really be focusing on. If your document viewer doesn't need to access the Internet, why does it have access to the Internet? Why does your general-web-browsing browser have access to your intranet and worse, your network drives and USB sticks? The reason we're stuck with what we have now is that operating systems research largely died in the 90s, but we're now aware that e.g. microkernel capability systems can be implemented in ways that are both fast and secure.
[1] https://www.cs.kau.se/philwint/scramblesuit/wpes2013.pdf
Expect “enterprise” network equipment using an approach like this to provide a “DOH firewall” in the near future.
Net privacy gained: negative.
The goal for DoH is to improve privacy for individual humans, and it does that.
No reason you can't get a real certificate, to ensure that your device talks to the server it intends to.
> If you're locked down... well, it's game over.
Devices today can already use pinned certificates and other similar measures to ensure that they only talk to the server they want to talk to. DoH doesn't make that any more or less effective, just simpler to get right.
You'd have to get a certificate for whatever domain the device wants to talk to - a domain you very likely have no control over.
No sane CA will give you a cert for that. The whole point of the PKI is to keep MITMs from pretending to be domains that they actually don't control - which is exactly what we'd be doing here.
If 90% of users leave it as shipped set to (say) Google, 9% switch to their preferred service and only a handful like you actually type in a DNS name, that freedom to do is preserved. If it doesn't check the certificate from the DoH server when you override the configuration, you are immediately exposed to a MITM so it needs to check. However you'll have no trouble getting a cert for your own FQDN, and that's what the poster you replied to is thinking of.
I believe there are ideas for a network-level autodiscovery of DoH servers, analogous to regular DNS. That would solve the problem, but I can't see how it would get buy-in from the DoH crowd, as it would tie DNS to the network again - and it would still have to be implemented by every single device.
Of course all of this is moot if the vendor actively wants to prevent you from intercepting DNS.
What DOH client would that be? Where would I configure it? How do I configure a systemwide DOH setting?
Right now none of those questions can be given a simple answer. DOH is a rogue technology.
And don't forget that you can change the resolver today, as you can install uBO, but what about tomorrow?
No. Run your own DoH server, point your DoH client to your own DoH server, and your DoH server can then provide any responses you want. (And it in turn can use DoH or do standard recursive resolution.)
End-to-end encryption means that malicious parties can't MITM your traffic or otherwise make you talk to the wrong destination server. That doesn't prevent you from intentionally running your own local servers and pointing clients to them.
If you have a client device on your network that you don't trust and can't change the configuration of, it has far more secure methods for protecting itself from you than just using DoH.