That is a good write-up on Paul's comments. I think he has an account here on HN. I recall discussing similar concerns here on HN when the protocol was first being discussed but I think most of my concerns were largely ignored. People were enamored by the idea of DoH but I see it as exacerbating a few problems.

It does not really address the issue of privacy unless one is only making DNS requests and not doing anything with said DNS results, as encrypted SNI is still not widely adopted. I guess I would call that cart before the horse. It does not prevent an abusive ISP from blocking access to a site as they can just block all the DoH resolvers or just NXDOMAIN the canary domain which also turns it off by default on most browsers. The bigger issue to me is that it doubles the number of organizations that can track behavior. Now my ISP gets this data and so does Cloudflare if I am the type to leave things default as most people are and they know it. CF may not wish to block something but should they receive a court order from any country they do business in then most people will lose access to something. That could be a future phase we have not yet reached due to mass adoption not reaching a set goal at this time. This is also a one-stop-shop for law enforcement to gather browsing data vs. having to issue a court order to each ISP.

Some people mention it protects against rogue nations but they are by far the last people that DoH would be useful for. Rogue / bad / totalitarian nations will just null route anything they suspect to be a DNS servers not in their control and will extract people from their homes to re-educate them. In a way I can see DoH as being a risk to people in such situations. Meaning they could be accused of bypassing some state level control and may not even realize they were.

In my opinion DoH/DoT should have been highly customizable in a GUI before it was ever implemented and default-off, default opt-out settings and instead if the browser or ideally the OS recognizes it is in a shared WiFi then maybe prompt the person to temporarily enable DoH. That's another issue, it's in the browser and not the OS. So the browser gets protection but nothing else does at least for the last few years. That is coming soon to some operating systems. Curious if they make it obvious what DNS partnership is in place.

I reroute all DNS queries attempting to leave my network to my DNS server. It won't work in scenarios where there is DoH without user consent, however at that point I should reconsider purchasing such hostile devices.

The heavy-handed solution looks like this:

    local-zone: "api.someapp.com." always_nxdomain

Then I reach out to them and say something to the effect of, "Hey, nice application/device you have there! In order for anyone on my network to utilize this app/device the DNS would need to be put back into your DNS servers and removed from the API records." Of course they will laugh at me but that is fine given that 100% of the internet and internet connected devices are entirely optional for me. It is unlikely that a statistically significant number of people would use this heavy handed approach. Or perhaps I am OK with their API method and make use of their API that bypasses DNS. This probably depends on if this is malicious or not. i.e. serving ads or malware

Another heavy-handed option would be to force all traffic through a MITM proxy which I have done in the past. Any device that can't have my CA cert loaded would be a paperweight and thus returned to Amazon with less than 5 stars and a review that details the DNS implementation which most customers would not care about or understand but my fellow cranky network admins may find useful. If it's a website then I would just not use it. Some businesses take this approach. There are both commercial and open source solutions for this. Look for Squid SSL-Bump MITM proxy if one is curious. This requires bypasses for domains still using public key pinning which is an insignificant number of them. Most have moved away from HPKP due to the induced fragility and risks.

There are other methods but they come with security implications such as decompiling applications, shimming something into it or pre-loading libraries to do the same thing but this usually requires rooting a device and potentially compromising security as the vendor signing may be removed. I'm sure some of the mobile developers here have more elegant and secure methods.

I doubt many would do any of this of course, but you asked.