In reality what's happening is a conflict between the security goals of network operators and those of end-users. Vixie, who runs a company that provides security services based on passively observing DNS, believes DoH sacrifices the security of networks in favor of end-users, and he's right. But:

1. In most situations, the end-users are the ones that matter; the cart shouldn't drag the horse.

2. In situations where that doesn't hold, serious security teams already exert direct control (via MDM and endpoint security) over end-systems anyways; why should anybody give anything up to make things easier for enterprises who are just a bit concerned about security, but not enough to take responsibility for endpoint security?

>DoH sacrifices the security of networks in favor of end-users

I agree, if you are considering the approach of just using an arbitrary DoH server. But I think it would be nice if people would at least acknowledge that this is not a fault of DoH. One could envision a future where local DNS servers could support DoH. I don't know how far away from reality this is, though.

If this is somehow a fault of DoH, I apologize for my misunderstanding. I admittedly haven't read the full standard.

>serious security teams already exert direct control (via MDM and endpoint security) over end-systems anyways

Thank you, this is precisely what I was thinking.

It's not at all a fault of DoH, since preventing "control plane operators" from coercing end-users into giving up their privacy is DoH's primary goal.

End users are not coerced by operators, they are the operators on their own devices and can do whatever the hell they want. The primary goal of DoH as proposed and implemented is to take away that ability from end users, hide that control from them. It's nothing more but malicious anti-user behavior.

This is obviously false.

> Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass.

That's assuming the clients and the network are adversarial to each other. Consider that the local DNS resolver may be blocking domains associated with malware or ads, which the client wants for it to do, and then changing the default DNS from the one configured via DHCP results in clients getting malware and ads they didn't want.

> While this can be true, it’s not actually anything to do with the way DoH works. You could just as easily choose to only upgrade to DoH when the DNS provider of your choosing happens to support it.

The major criticism of DoH is Firefox enabling it by default and overriding the existing system DNS configuration, requiring manual reconfiguration of arbitrarily many client devices to change it back to the way it was. There can obviously be no legitimate objection to it if it is disabled by default and only used when explicitly enabled by the user.

> Home internet is not new or uncommon. 76% of the US has internet access according to a cursory Google search. A vast, vast majority of these users are casual users. The control plane is not under their control necessarily. The control plane is not something that can just absolutely be trusted.

This is a great argument for making DoH/DoT/DNSCurve/etc. the default configuration for the builtin resolver in home internet routers. Which thereby solves the problem without introducing a new one where if you want to change the default it requires reconfiguring arbitrarily many separate applications on every individual client device, because in that case you can still configure the DNS for the local network in one location.

"The major criticism of DoH is Firefox enabling it by default and overriding the existing system DNS configuration, requiring manual reconfiguration of arbitrarily many client devices to change it back to the way it was. There can obviously be no legitimate objection to it if it is disabled by default and only used when explicitly enabled by the user."

+1 Firefox should also consider that such network settings are only accessible to root or administrators such that organizations can maintain network policies for the devices they own in their network.

Adversarial networks are the common case.

In the other cases, where DNS is being used as a legitimate policy vector, the entity enforcing that policy should also have endpoint control, which they can use either to re-establish network policy (by disabling DoH) or to enforce policy more reliably at the endpoint layer.

Adversarial networks are not the common case. On the majority of networks you can send a plaintext UDP DNS query to 8.8.8.8 or 1.1.1.1 and nothing will actually interfere with it in practice.

Adversarial networks exist, which is why something like DoH or DNSCurve should be used in favor of unauthenticated DNS over the internet, but the real issue here is independent of which DNS protocol is used -- it's how the recursive resolver is chosen.

The canonical answer to that is to use DHCP or similar to distribute the resolver that should be used for the local network, and allow the user to manually configure a different one in any case where that one is untrustworthy. DHCP is the ordinary method of endpoint control for configuring the endpoint's DNS server.

The endpoint shouldn't have to be exposed to manual configuration or give up even more control over other unrelated settings by adding their device to something like a third party Active Directory domain just to be able to plug into a local network and have local name resolution work.

Your threat model isn't the set of actors currently attacking you, but rather those actors who can and might attack you in the future. Your ISP is certainly adversarial in any sane threat model.

Aren't you the one usually telling everyone that DNSSEC is useless even though it solves the same problem, e.g. because the server can be verified with TLS instead? If the DNS attack is nothing more than a denial of service then it seems completely reasonable to wait until the attack is actually observed before applying a mitigation (third party DNS) that can have problematic side effects. Especially when the mitigation can be made as simple as a single checkbox in the browser.

And what makes Cloudflare any more trustworthy than the average ISP? Isn't that just switching the user's resolver from the network they explicitly chose to connect to, to a centralized third party that they didn't?

DNSSEC doesn't solve any practical problem, but does have the effect of escrowing TLS keys to world governments. DoH solves an immediate problem, which is that ISPs (and other entities) passively monitor DNS traffic to collect intelligence on network users. DNSSEC does nothing about this problem.

You don't have to use Cloud Flare for DoH, and I wouldn't.

> DoH solves an immediate problem, which is that ISPs (and other entities) passively monitor DNS traffic to collect intelligence on network users. DNSSEC does nothing about this problem.

That's assuming the DoH provider isn't monitoring queries either. Doesn't Cloudflare have a deal with APNIC to do exactly that?

> You don't have to use Cloud Flare for DoH, and I wouldn't.

That's the point -- the problem isn't that DoH exists, it's when an application changes your DNS provider to Cloudflare by default instead of using the one you have in your system configuration.

You can trivially boot up your own DoH provider if you don't trust any of the existing ones. It's hard to imagine a protocol that would improve this situation: "supported by major vendors, and free to use for everyone".

I won't use Firefox to begin with (I'll reconsider when it's mostly Rust!), and so don't care so much about how Mozilla is handling this. Personally, I wouldn't touch Cloud Flare with a 10 foot pole. But that's not what I'm commenting about; I'm talking about DoH itself, which is an unalloyed good thing, which you can tell in part by the fact that the knives are out for it.

"Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass."

Same argument can be done for firewall that filters traffic using IP addresses. In the same words, it can be said that, if your firewall security policy can be defeated by using VPN, its evidently not very hard to bypass.

Just like firewall is useful for security, so is DNS based policies.

Cloudflare is doing good job but, the concern is centralization. Its not going to be good to have most internet resources being resolved via Cloudflare DoH, then accessed via Cloudflare CDN.

ESNI will take a lot of time to gain meaningful market share. There are people still arguing that their website does not need to use HTTPS since they are just a static website or do not have login/user data. Such people completely fail to understand that HTTPS is not to protect them but to their end users from MiTM script injection attacks.

> which is bypassing the control plane

This is not bypassing the control plane, this is the control plane. Each device is essentially its own network that connects to other networks. This is how operating systems work today.

> You can still configure your resolver today.

Yes, because of people who pushed back Mozilla.

Do you have an argument that would be persuasive to people not in the alternate universe where resolvers weren't configurable?

Even if Mozilla did make Cloudflare DoH mandatory, which to be honest is ridiculous and not a real thing that was ever happening, it’s not as if you have to use Firefox.