There are plenty of valid arguments against DoH. If DoH becomes common, it most likely will resemble the situation with DNS resolvers we have today. Meaning, there would be the eternal problems inherent to centralization. I.e. both that the centralizing powers would have enormous power to disappear something off the internet, but also that the central servers would recieve huge amounts of constant real-time data of what everybody was doing.

We need something to encrypt and authenticate DNS, but that exists in DNSCurve. The problem with it is that it doesn't try to hide what it is, so an adversarial middlebox can detect and block it to try to force you to use their own DNS.

DoH is an evolutionary response to that, because it looks like HTTPS to Cloudflare, which is difficult to reject. And that's terrible for a lot of reasons (inefficiency, complexity, centralization), but it solves the local interference problem. Which means that's what we're unfortunately going to end up with unless we can solve the interference problem another way, i.e. make intermediaries understand that they're going to lose anyway and it's better to allow unmolested UDP DNS/DNSCurve to the endpoint's choice of recursive resolvers than to have everything using DoH to Cloudflare.

There are two available courses of action. Option one: We embrace something like DoH in order to avoid any possibility of blocking and detection. But you then have no simple way to back out from centralization if/when centralization (almost certainly, IMHO) slowly becomes a problem. Monopolies and oligopolies are hard to break once formed, and absolute power corrupts absolutely. Option two: We use DNS like always to avoid problems with centralization, and adopt a secure DNS protocol to avoid spoofing and unauthorized monitoring. If we do this latter thing, and detection and blocking does become a problem (and it might), we can always add some additional layer of security, like HTTPS tunneling, on top, which avoids it. We could even, if it became absolutely necessary, centralize after the fact; but this way, we can avoid it until it would become necessary.

I would prefer not to centralize things in advance, just in case a certain problem develops. I would instead prefer to keep it de-centralized as long as possible, and solve individual problems as they actually occur.

I would also prefer DNSSEC and DoT over DNSCurve, and I would suggest IPsec with opportunistic encryption to be a more pure goal than to tunnel everything over HTTPS, but my preferences in protocols are not important to any of these points, and we don’t need to argue about that.

We're already there. There are already ISPs in some parts of the world redirecting DNS queries to any DNS server to the ISP's DNS server, which gives invalid responses to queries that authenticate the DNS server (DNSCurve) or invalid responses to queries it can read and wants to block (DNSSEC), either of which is an effective denial of service attack. Which drives adoption of ugly DoH.

The root problem where the centralization comes in (because you could actually do DoH to something that isn't Cloudflare), is that you need to trust someone to faithfully and completely answer all of your DNS queries without dropping any of them or sending invalid responses for queries they don't like.

That used to be your ISP, and we had a decentralized solution as long as the ISPs would faithfully answer all queries, but what happens when they don't? You need someone else. "Let everyone choose for themselves" is a theoretical answer, but in practice the average person doesn't know anybody who runs a public recursive DNS server, and Google and Cloudflare are easy and "free", so everybody will end up on them. To prevent that we need ISPs to stop interfering with DNS.

This seems like an authoritarian argument rather than cybersecurity. It’s hard to say what’s a valid or not valid argument, but I think if a university is trying to limit malware, then blocking DNS won’t do too much.

No. Institutions are fully capable of doing whatever filtering they wish. They always were and always will be. Period. Full stop. Howgh.

They can and should secure their network, watch out for data exfiltration anyway, etc.

They should disable ever kind of network traffic that does not go through their auditing/filtering proxy (HTTP, DNS, SMTP or whatever).

If they want to support bring-your-own-device, great, configure said devices, set up proxy-auto-configuration, hand out "how to set up your device to work on corp-wifi" flyers, and in general, they have their IT team, let them work and they will figure this out.

The old way of just MITM-ing was always bad for at best it was/is lazy, but in reality it's quite unprofessional and counter-productive for security.

Just out of curiosity, though, how could I block network traffic that did not use a specific DNS server to progress? Even on public wifi, like Amtrak, where I am required to use a captive portal on first connect before anything can be done, I can, after accepting their TOS, re-load dnscrypt-proxy and be back on my merry way. In addition, some things don't even need DNS to function at all (what if I memorized the IP? What if the IP is hard-coded in?)

They could probably say "drop all requests to 1.1.1.1, etc." but nothing is stopping me from running my own DoH resolver that they would have to manually scan for.

They could always just have a whitelist or force you to use their TLS cert so they can decrypt everything, and they'd just block anything that they can't filter. If they're using a whitelist and you need to access something, they check it out and add it to the whitelist if it seems reasonably secure.

That being said, I absolutely hate all the filtering crap, so I actively avoid working for any company that decides it needs to see everything I'm doing online.

>I actively avoid working for any company that decides it needs to see everything I'm doing online

So in the interview, you actually ask, "do you have a filtering proxy to monitor workers internet traffic?"