The correct solution is a) do this at the OS so users can configure the behaviour, b) add support to pihole or similar for making DoH requests out to somewhere like CloudFlare, c) also add support for receiving DoH requests for those people using a pihole over untrusted networks.
The problem you are describing is nothing to do with DoH, it is simply a consequence of the fact that DNS is not meant to provide access control. It is not an endpoint security management solution.
That said, in fairness, not everyone sets up their own VPN mesh. Some people use commercial VPN providers. So in that case, it would assume my friend does not block access to that VPN provider.
[1] - http://tinc-vpn.org/
You could block your guest's VPN connections, but you don't do that.. why not? Aren't they subverting your protection by using VPNs?
> nor would I subject them to centralized DNS. Both are equally dangerous in my view.
I would argue that large providers like Cloudflare are the only ones who realistically have the resources to stand up to threats like government intervention (where it is possible). They have strong legal and financial incentives to maintain their privacy guarantees which smaller providers don't have.
Also you have the advantage of your data "hiding in plain sight" due to the high volume they deal with.
I certainly wish there were more providers available than just Cloudflare and Google though.
For my technical friends, that would be true. They can adjust their settings and be on their way. I won't block their choices aside from intercepting requests to the ISP DNS.
Most of my friends are not technical, have no idea how to tweak the settings in their browser and would not know they even need to care. So I think it is fair to say that a choice is being taken away. It isn't like browsers are going to prompt people and explain what is occurring. The masses will experience centralized DNS without any idea this is happening. I think we will fundamentally disagree here.
You could block your guest's VPN connections, but you don't do that.. why not?
My guests can choose to use a VPN if they wish, I would not take that choice away. That is an intentional move to protect their traffic. DoH is not an intentional choice. They did not choose this. If a technical friend chooses a DoH server, their laptop won't work and I will explain, if I had not already, that DoH servers are blocked. Anyone that knows me, would expect this behavior. Anyone that is my friend would accept this. We probably just have very different circles of friends.
Although if the only concern is that Firefox defaults to a poor choice (in your opinion), why not just block Firefox's default specifically? Why other public DoH servers too? Or why not just block the Firefox DoH canary domain which prevents it from defaulting to DoH unless the user specifically turns it on?
At work, we already control these settings in the browser and can easily control any future settings in the OS so it is not an issue there.
I hadn't looked into this recently but it looks like you can configure a pihole to use DoH for outbound requests:
https://docs.pi-hole.net/guides/dns-over-https/
So personally I plan to a) enable that so my outbound requests are encrypted, and then b) install a DNS blocklist so the hosts on my network will fall back to regular DNS and use the pihole.
Best of both worlds!
On every app that will be baking in their own DNS resolution. Here's to hoping they all allow it to be changed via configuration. I suspect a favorite feature of pi-hole, blocking DNS from opaque devices like phones and TVs, will also cease to work when they use DoH too.
How do I enforce that? How can I ensure that no javascript payload or "smart" device on my network or app on my phone is connecting to a DoH server, when they're on my home network?
You don't. When the device manufacturers start being really evil and using certificate pinning for their DoH servers you simply don't buy those devices.
When the only devices available in the market for a given function end up being "evil" you either implement the functionality yourself or you just live without.
It's that or legislation (which will just become an arms race of manufacturers trying to work around the legislation).
I do without. No "smart" devices for me or my family. It's working so far. I about the eventual future when no major appliances, vehicles, etc, will be available without "smart" features implemented in an owner-hostile manner.
This removes a couple of avenues of attack you might have used to rein in some of those devices (but probably weren't doing), but it's just a symptom of the fact that using DNS for device control was always a really hacky, kind of awful solution to the problem of having rogue devices on the network.
Plus, right now we're talking about a browser adding DoH, and not some shit Google or Apple browser that makes the decision for you and it's final, but a fully configurable, user controlled, poweruser enabling browser that lets you modify its core behaviour without even having to recompile it yourself. You just open a tab and flip a boolean.
There is no problem.
This is so obviously bad I don't understand.
So given that DoH has real and practical security and privacy benefits, and non-DNS based content blocking solutions are already available, are more common, and work more effectively, I don't see how it is such a nightmare to adopt those more secure defaults for everyone.
Furthermore I don't think anyone is suggesting "100 different applications" will each have their own resolvers embedded. It makes sense for browsers to be a special case since they are particularly in need of the additional privacy affordances that DoH can provide, and operating system vendors have been slow to implement it.
I think you're missing the point, here.
A lot of enterprises run their own delegating DNS server for a variety of reasons that have nothing to do with ad blocking.
DoH breaks that en masse.
Firefox has always struggled to gain adoption in corporate settings, and this looks like a nail in the coffin .
Of course that could be easily bypassed, but such a restriction could be easily bypassed by determined employees regardless of whether Firefox natively supports DoH or not.
Local intranet sites will still continue to work without any changes because by default it will fall back to the native resolver if DoH can't resolve the domain. So there should be no breakage by default besides for content blocking use cases.