1. 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.
2. 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.
3. 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.
With much respect, I simply must disagree. The notion that DoH is dangerous feels like it comes from a dated view of internet security, and it only reflects the mode of rollout where application software indiscriminately uses a DoH server in place of the user’s default DNS server.
Further, this article has a lot of interesting claims. It claims that many websites are still not running over TLS even though it’s free. Of course, this is undoubtedly true and reflected in statistics. However, is it true in a realistic sense? How many non-HTTPS pages do you browse?
Thanks to Cloudflare and other actors, I suspect ESNI will have no trouble gaining meaningful marketshare. Not full proliferation. We don’t need full proliferation for it to be useful, though.
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?
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.
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.
+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.
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.
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.
It is. They can even install a VPN everywhere they want, that's how much control they have. DoH wants to take it away.
> I suspect ESNI will have no trouble gaining meaningful marketshare.
You have not been paying attention. Those same organizations removed the exact ability esni proposes once governments applied a bit of pressure on them (I'm talking about collateral freedom domain fronting thing).
The network control plane is not on the end user’s computer. For a home network, this is probably their ISPs modem, followed their ISPs actual edge. You could opt to set up your own DNS server or use an alternate DNS server, which is bypassing the control plane, assuming your ISP doesn’t force you to use their restrictive equipment.
The difference between DoH and regular DNS here is that even if you choose another resolver, unencrypted DNS can still be intercepted, logged, and modified by the control plane; many providers have been doing this to monetize NX DOMAIN responses even when the user is using another DNS resolver. I first realized this when attempting to get rid of annoying NX DOMAIN search SPAM pages on my phone years ago... That is precisely why this issue is coming up now and not earlier when cleartext alternate DNS resolvers gained some popularity.
> DoH wants to take it away.
What does DoH take away? You can still configure your resolver today.
> You have not been paying attention. Those same organizations removed the exact ability esni proposes once governments applied a bit of pressure on them (I'm talking about collateral freedom domain fronting thing).
What have providers removed from ESNI?
I'm still waiting to see a genuinely technical disadvantage of DoH. All that I've read so far are social and implementation related issues that can be ironed out over time.
Currently, the only way to configure it is manual and application-specific; there's no way to configure it for all apps and automatically, like DHCP for the normal, 53/udp DNS. Nobody is going to manually reconfigure their DNS every time they switch network (e.g. home -> office -> customer).
edit P.S: I'd never trust ISP's DNS servers, because it's the easiest way to track what customers does.
Wouldn't be a proxy checking the SNI of connections you open better?
Lack of privacy issue aside, there are a bunch of technical disadvantages compared to alternatives. Like using encryption to a local resolver or to a resolver over trusted or encrypted network is unnecessary overhead and complexity, including operational complexity that you really want to avoid. And if there is a case to use encrypted communications with a recursive resolver (i.e. non local), it could be done by simply tunneling DNS protocol over any of existing crypto protocols, no need for yet another complex protocol tunneled over https that still has to be converted to a native DNS protocol down the line.
As for not using TLS/http to wrap the dns queries for secure transport across the net, what “existing crypto protocol” do you suggest they should have implemented instead?
https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
My home network has a DNS server that already talks to the outside DNS servers with TLS, so having browsers reach out to cloudflare would prevent cross-device caching and only protect against snooping on my LAN or wifi, which I don't find to be very necessary. So I just made this domain return NXDOMAIN.
This is a totally wrong usage of DNS and I wish we would focus more effort into making IP-based blocking easy and accessible rather than wasting time trying to make DNS fit this niche. DNS is not the right tool for this job and maintaining this functionality is not a valid reason to block progress on more private technologies like DoH. And it's totally possible to run a PiHole-style system using DoH anyway.
Users access services by DNS name, so if you want to control access it has to be at that level. Whether DNS can be effectively blocked while maintaining privacy is another issue, but I can't see IP-based blocking helping here.
- proxying ad requests through the server of the website you're visiting;
- accessing ads by IP address directly; or
- using randomly generated domain names.
With a browser-based ad blocker, those measures would still be an obstacle, but at least you'd have a chance - you could switch to more heuristic ways of detecting ads based on, say, the scripts involved, or the content of the media being downloaded, or its size and placement on the page. None of that information is available to network-based blockers, at least not when HTTPS is in use.
Admittedly, those things probably won't happen anytime soon, at least not for regular website ads. (Though as one example, Twitch has already started using fairly sophisticated measures to bypass ad blockers for their video ads...) But I'm an idealist, and I like to fight on favorable territory. When it comes to cat and mouse games, I don't want to be the mouse.
Instead, any blocking needs to be done on the device, whether it be MDM for any business-related blocking or via Parental Controls/Restrictions for blocking porn.
however, your statement is wrong.
i won’t go further into detail because my comments on this subject universally attract all the downvotes so there’s no point. but in general the problem is you need to qualify “safest”. safest for what and for whom, and in what scenarios? you’ve left too much unsaid, so what you say is not generally true.
At least a comment that attracts downvotes may be useful to someone.
In theirs, they read the DNS servers from the OS (like the original), and then if it's part of a list of known DoH providers, they try to connect over DoH before falling back to regular DNS queries.
Virtually all the opposition to DoH is rooted in two complaints:
1. It centralizes DNS at Cloudflare (obviously, you can point DoH elsewhere).
2. It's hard for network operators to block it (which is the point).
That only fixes the "Cloudflare" problem. It still centralize all DNS traffic onto a single service. I cannot configure Firefox to send packets only to the (hypothetically DoH capable) delegated nameserver(s) for each domain.
When you run your own recursive resolver (which is easy), only the lookup of the NS delegations needs to use a centralized service. This is relatively infrequent (NS records rarely use a very short TTL), so regular (TTL-respecting) caching prevents the centralized service from learning your pattern-of-life.
The DNS traffic for the A/AAAA records[1] is very different. Short TTLs are commonly used to force a DNS check every few minutes. In practice, this means a user's aggregate DNS traffic contains a very good pattern-of-life about the services they use and when they use them. When you run your own recursive resolver, nobody can learn the entire pattern-of-life; the traffic is distributed to different servers for each domain delegation.
If I could configure DoH at the system level, as I do normal DNS, I'd be perfectly happy. As it stands, DoH could trivially be co-opted by browser vendors to ignore system DNS settings, and even if it isn't, it still makes DNS configuration a worse experience.
