> If you're on current macOS/Windows/Linux/Android/iOS/ChromeOS you probably just want to configure DoH or DoT at the operating system level so it is done system wide.
Indeed. The problem is that a lot of operating systems still don't support it at all yet.
> The other half reading this probably want a "how to force disable" guide instead of a "how to" guide.
Sadly, yes. And the only reason I've heard for this is that they want to be able to censor or surveil traffic from other people's computers.
I'm actually in the "how do I force disable" camp for reasons unrelated to other people's computers.
On my personal network I've got an inside view of my domain that will resolve internal services if you hit the resolver from the inside, this breaks if an external resolver is used and it'd be more work for no real gain to set this up as an internal DoH resolver and make sure clients used that.
On my work laptop I have a similar need for split resolution in many cases, particularly when connecting to customer's networks. I also have an additional need to be using the same resolution flow as their computers when troubleshooting, if one of their DNS servers is misconfigured I'll never see the issue resolving to an external server.
I've not found the browser fallbacks to fully cover the 2 above scenarios and, even for the parts that are covered, I've not seen it be particularly reliable. Particular if you switch networks often.
I've also seen people against browsers pushing users to fewer centralized services but I'm not really in that boat myself, I point DNS to 1.1.1.1, 8.8.8.8 anyways.
That said I run across a lot of customers that don't understand it's easier to build and enforce a proxy config on a managed fleet than to try to play whack-a-mole with every user packet that doesn't match this policy and try to avoid DoH at the network layer as a result. I don't really expect this to change until security auditors stop accepting these implicit policies as meeting requirements. Outside of finance/government that still seems forever away.
> I'm actually in the "how do I force disable" camp for reasons unrelated to other people's computers.
I think you're actually just in the much smaller but perfectly legitimate "how to disable" camp, rather than the evil "how to force disable" camp, since you're not trying to keep someone who wants to use DoH from using it.
> On my personal network I've got an inside view of my domain that will resolve internal services if you hit the resolver from the inside, this breaks if an external resolver is used and it'd be more work for no real gain to set this up as an internal DoH resolver and make sure clients used that.
Do the domains in question resolve to other IPs on the outside, or do they not resolve at all? If the latter, then Firefox will automatically fall back to local DNS when DoH fails to resolve them. If the former, then I can think of three other solutions that don't require disabling DoH altogether: either switch from split-horizon DNS to NAT reflection, configure Firefox to disable DoH for just that domain and its subdomains, or add IPv6 addresses for them since it doesn't get NATted.
> I also have an additional need to be using the same resolution flow as their computers when troubleshooting, if one of their DNS servers is misconfigured I'll never see the issue resolving to an external server.
I agree that this is a legitimate reason to turn off DoH for yourself (assuming that your customers don't use it themselves, of course).
> I think you're actually just in the much smaller but perfectly legitimate "how to disable" camp, rather than the evil "how to force disable" camp, since you're not trying to keep someone who wants to use DoH from using it.
Yeah not other people's setups (not sure how to do that but it's an interesting question actually, maybe dynamic FW rules trigger by the local resolver's responses?). "How to force disable locally" would probably be the precise term. What I mean by that is network.trr.mode has 5 settings:
- 0: Off by default
- 1: Reserved (previously used for deprecated functionality)
- 2: Secure resolution first
- 3: Secure resolution only
- 4: Reserved (previously used for deprecated functionality)
- 5: Off by choice
and defaults to 0, disabled which may automatically switch to 2 on you in certain circumstances. I switch it to 5 which forces it to stay disabled regardless if Firefox rolls it out automatically in my region or thinks DoH would work correctly in the currently connected network or changes how detection/deployment works in the future.
> Do the domains in question resolve to other IPs on the outside, or do they not resolve at all?
Different, apart from avoiding needing external NAT+FW rules for an internal service my LAN is 10G but my NAT capable router is still only 1G which can surprisingly make a difference pulling files or accessing KVMs and so on through my personal portal.
> If the latter, then Firefox will automatically fall back to local DNS when DoH fails to resolve them. If the former, then I can think of three other solutions that don't require disabling DoH altogether: either switch from split-horizon DNS to NAT reflection, configure Firefox to disable DoH for just that domain and its subdomains, or add IPv6 addresses for them since it doesn't get NATted.
Or just set DoH to force disabled Firefox and avoid rebuilding my network around something that nets me no gain. My external name resolution is already secured, my internal services already work, and I'm already using the most performant path. The only thing I need to set is network.trr.mode to 5 and I'm golden as Firefox .
> If the latter, then Firefox will automatically fall back to local DNS when DoH fails to resolve them.
As stated I've not found the fallback detections to be foolproof. E.g. on top of split-view DNS some organizations point a wildcard record to their landing page meaning any request to the domain always successfully resolves.
Yes, if you're just setting network.trr.mode to 5 on your own systems and not trying to interfere with other people's usage of DoH, there's nothing wrong with that. I'm glad to hear that's all you're doing.
In that case, you can just disable it the normal way on your devices in their end-user settings. That's still not a reason to try to block it at the network level.
Also, it's a bad thing if you have a reliable way to block any device on your network from using DoH, because then you'd have a way to block other people's devices from doing so, and so would the rest of the adversaries who want to censor people.
>Indeed. The problem is that a lot of operating systems still don't support it at all yet.
Which one exactly? Android has it called "Private DNS", Linux supports it with systemd-resolved, Windows 10 too (don't know the build number at which it starts). Apple with OS 11 and iOS 14.
The main issue I see is that there is no support for both in every OS. "Private DNS" is DoT, while Windows 10 support is DoH. Apple has both.
DoT is worthless since it's so easy to block at the network level, so I'm not counting Android. And doesn't Windows 10 only support it if you're in the insider program?
Depends on the client. You can construct any viable scenario here, won't matter. Right now you can block DoH too, simply by blocking Cloudflare, Quad9 and Google.
Indeed. The problem is that a lot of operating systems still don't support it at all yet.
> The other half reading this probably want a "how to force disable" guide instead of a "how to" guide.
Sadly, yes. And the only reason I've heard for this is that they want to be able to censor or surveil traffic from other people's computers.