This is a tactical move to obfuscate and make port filtering more difficult because suddenly DNS uses the same protocol and same port as 99% as your traffic. This is versus DNS-over-TLS that offers the same privacy BUT still uses a DNS-specific port so is easier to detect and block. Of course you can still block by IP...
Other than that, it is exactly the same DNS messages. It's just that they are encoded in HTTP messages.
DNS-over-TLS uses port 853, so is trivial to block on a firewall and force fallback to plain-text DNS.
DoH is resilient to such an attacker - be it sketchy guy in starbucks trying to steal your cookies, or yourself trying to run pi-hole adblock.
If you are smart, at this point you'd have already switched to a DoH server using your own certificate (I use a local AdGuard Home instance for that). You can then point not just your browser (either using its configuration page or group policies) but also the operating system and secure the whole thing. After that your only threat is the same as it has always been, a device bypassing your local server, it is safe to assume those are compromised and should be put behind a firewall or disconnected from the network (it is also safe to assume that a firewall rule to capture and modify its DNS queries has never been a 100% reliable solution).
DoH already happened, there's no point in arguing against it like it's the end of the world as we know it. It's now time to adapt and update (or replace) the blocking mechanisms we are used to using. This may mean the end of pi-hole should they fail to add a DoH server to the default installation but we already have alternatives.
The downside is, of course, that Starbucks can't redirect you to their "please accept our TOS" portal.
Can't easily block all port 443 traffic (may as well not give any service), and as servers grow maintaining a blacklist of DoH would be problematic - especially when the DoH server is hidden behind normal sites on cloudflare etc.
Of course a sysadmin can always establish a VPN on any port to any IP with TCP, UDP, ICMP, or even running a VPN over unencrypted DNS, and bypass all that network work other than very specific IP whitelisting.
As a network admin and a sysadmin, I want to be able to control my systems from my network without losing control. I like the idea of DoH, I just don't want to have to reconfigure my DoH server everytime I want to connect to a split-brain network, or have an alternative PTR server, and I certainly don't want my browser using a different source for DNS to my other applications.
I don't see things as you do. Specialised protocols are better than generalised ones because they have understandable failure modes.
If DNS goes down, name resolution fails. But if DoH goes down, it could still be DNS, it could be TLS Suites, it could be incorrect headers, it could be mishandling of the proxy (or the proxy forwarding garbage), it could be anything.
that's why we consider DNS to be Layer 6 and not Layer 7, as things on Layer 7 may depend on it.
There are significant benefits to the end user of DoH in bypassing malicious networks. It's out there, it's not going away. I'd like it to integrate well in a situation where I am the user, sysadmin and netadmin.
unless you're saying we should replace SSH with HTTP.
And yes, DNS is easier to debug than HTTP if HTTP depends on HTTP.
The idea of these new transports is not to impact existing DNS.
It encodes the wire format DNS messages in Base64 for requests and plain hex for responses (rfc8484). That's basically only an adaptation layer to fit into http messages.
Which is good because, really, there is no need to change DNS messages and this makes implementation easier. The aim clearly is to add a new transport for messages with as little impact as possible.
Cloudflare also has the JSON format available[3]
[1]: https://groups.google.com/forum/?fromgroups#!topic/public-dn...
[2]: https://groups.google.com/forum/?fromgroups#!topic/public-dn...
[3]: https://developers.cloudflare.com/1.1.1.1/dns-over-https/jso...