People don’t take issue with DoH, they take issue with an advertising supported browser like Mozilla’s unicast (and now bicast) centralization of DNS traffic that was previously distributed.
We invented DNSCrypt. There’s also DNS over TLS. Lots of ways to encrypt DNS without centralization.
They make this about DoH when really the primary issues are with how they went about it.
DNS over TLS and DNSCrypt both depend on servers... exactly as centralized as DoH. They are just different wire protocols that in the end do the exact same thing with a centralized DNS server.
In fact, the only meaningful difference between DoH and DoT is that DoT runs on a separate port, so network operators (and ISPs) can filter it. DoT is DoH with a kill switch.
DoH can be blocked by IP addresses, DNS canary and probably SNI, while DoT by IP addresses and port number. So "DoT is DoH with a kill switch." is again nonsense.
Virtually every router on the Internet has the built-in capability to block DoT with a single configuration change, but you can attempt to create a blacklist of DoH resolvers to try to stop that, so they're totally equivalent. That's the argument you've got.
Nothing prevents Google or Cloudflare to run DoH on the same IPs as their user-facing services. Unless you are willing to block Search, for example, you might be SOL without TLS-terminating proxy.
So one is easy to block and the other is hard, requiring maintaining a blacklist and or deep packet inspection. I'll take the hard one please.
Just increase the cost/difficulty of a thing makes that thing less common. In this case that "thing" is ISPs selling highly accurate web histories to anyone who will pay. Please make that harder/more expensive, every cent of cost to the ISP is welcomed.
This is not the full picture if we are being honest with ourselves. When DoH is default on in all browsers, the masses will be talking to 2 or 3 companies. Sure, they can change what server they talk to, but we all know that most people won't even think about it. DoT implemented on all DNS servers would keep control as distributed as it has been up until now. Until the root serves support DoT, which I doubt they ever will, there will always be weak links. This includes from Cloudflare, Mozilla and others talking to the root servers. I am not trying to convince anyone of anything. This is a very polarizing topic and has been every time it is discussed here and other news aggregators. The best I can do is educate people that I care about so they can make an informed decision.
People keep talking past each other on this because somehow DoH got conflated with Cloudflare.
DoH is a protocol. It has better security than unencrypted DNS. (So do several others, like DNSCurve, DNSCrypt, or routing your DNS queries over a VPN.)
The objection people have is not that it's encrypted, it's that Mozilla implemented it in the browser instead of the OS and thereby ignores the DNS you configured in your OS. And even that is fine as a setting you can enable, but it's problematic as the default. Both because it's administratively burdensome to change a setting in every application on every device if you want to use your own, and because of the second order effect of that, which is that hardly anybody will change it and then DNS becomes centralized to whatever is the default in the browsers.
If you're worried about your ISP snooping on you and tampering with DNS records, the tools we have today already offer better privacy and trust than DoH, DoT, DNSCurve or DNSCrypt.
Just use a DNSSEC capable resolver in combination with a VPN. All other options today are effectively theater.
DNSSEC is the least useful of the lot. It only authenticates, doesn't encrypt, so it's not enough on its own, you have to use it in combination with a VPN. But the VPN would be enough on its own between the client and the recursive DNS, since it does both.
Between the recursive and authoritative DNS the VPN wouldn't exist, but if the attacker is there then DNSSEC is in trouble again because it still doesn't encrypt (no confidentiality). What can be used on that path is DNSCurve, because it does encrypt even where there isn't a VPN.
The majority of domains also aren't DNSSEC signed anyway, so it doesn't even authenticate them.
You're conflating privacy with trust. DNSSEC gives you trust, the VPN gives you "last mile" privacy. DoH is only designed for last mile so useless in encrypting the resolver chain between you and the root servers.
Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled). Over time you can hope for DoT to gain wider adoption so more and more of the upstream resolver chain is encrypted.
DoH mitigates the "ISP selling your DNS data" threat, which practically everyone in the US faces, without forcing all your traffic onto a VPN, which not everyone wants. Meanwhile: practically no important zones are signed, so apart from the fact that DNSSEC does nothing to improve privacy, it's also not useful. DNSSEC is moribund; taking steps to enable it is a waste of time.
DoT would also mitigate it in a similar fashion. In both cases mitigate doesn't really have much meaning since, sans VPN, ISPs that are inclined to do so will quite happily continue to find ways to infer where you're browsing to (IP address and CT log correlation being the obvious choices). Ergo, if last mile privacy is you're issue, the best bet is a VPN or some improved regulation so that consumers have a choice if they want an ISP that doesn't spy on them.
DoT and DoH have virtually identical service models. The practical difference between the two is that DoT deliberately runs on a nonstandard port, so that network operators can filter it. It's not an exaggeration to say that DoT is simply DoH with a network kill switch.
When was the last time port 995 or 993 were blocked? If the same adoption happened with DoT, ISPs wouldn't have the option - customers wouldn't accept it.
Confidentiality and authentication are two different things, but the things that provide confidentiality here also provide authentication. DNSSEC only provides authentication, so then you need something else to provide confidentiality at every point in the path. At which point you would also have authentication at every point in the path, so what does that leave for DNSSEC to do?
> DoH is only designed for last mile so useless in encrypting the resolver chain between you and the root servers.
This is true. DoH isn't the one to use between recursive and authoritative DNS servers.
> Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
DoT has a similar drawback as DoH between recursive and authoritative servers. The session establishment is expensive (more round trips, higher latency). That's not so bad for the link between the client and the recursive DNS, because you create a session once and use it for all your queries. It stinks between recursive and authoritative servers because the recursive server would need a new session for each authoritative server -- and a single recursive query can often require contacting three or more authoritative servers.
Fortunately DNSCurve has lower latency and can be used between any pair of recursive and authoritative servers that support it.
The root not supporting DNSCurve is an issue, but it has an obvious long-term solution (have the root start supporting DNSCurve), and in the meantime the recursive resolver could validate only the root with DNSSEC. The lack of privacy is much less impactful for TLD queries -- a query for your-local-oncologist.com tells an observer much more than a query for .com. Then if DNSCurve is used for the rest of the chain after the root, you have one authentication or the other for the full chain and privacy for all but the TLD query. You also then don't need any large DNSSEC records in the authoritative servers that support DNSCurve, which would otherwise be a DDoS vector.
> So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled).
I still don't see what that's even supposed to be adding over the VPN right now. The VPN handles the link between the client and the recursive resolver. You can only get authentication between recursive and authoritative servers for domains whose authoritative servers support some authentication, but hardly any of them support any authentication right now, and if you're going to add one it makes more sense for it to be DNSCurve than DNSSEC because it provides confidentiality in addition to authentication and isn't a DDoS vector.
DNSCurve sounds quite nice (I'm not at all familiar with it tbh). I agree something along those lines with DNSSEC for the last hop to the root would do it.
To be honest my main gripe is with DoH. For non-last-mile privacy/trust, there are indeed many suitable ways to tackle it.
While that is true, it would be much easier to get DoT deployed at scale. During DNS Flag Day of 2019 [1] a significant number of recursive DNS servers around the world started properly supporting EDNS0 and several other modern features of DNS. In most cases, it was just application version updates or configuration changes. Most of the popular and widely deployed recursive DNS servers already support DoT, which means that a similar effort could be made to enable DoT. AFAIK none or few of the popular recursive DNS servers support DoH today natively. It would be significantly easier to get DoT enabled en-mass. People are much more open to making a configuration change if that is the least path of resistance.
>> We invented DNSCrypt. There’s also DNS over TLS. Lots of ways to encrypt DNS without centralization.
Ummm so what’s the downside then? Are those services arcane and hard to use and utterly forbidding blackest black magic, like almost all crypto stuff?
If you’re thinking browser users will just do this then that then this and x and y and z to “get dns crypto going”, then I’ll take Mozilla’s “it just works” approach.
It’s a much much better approach for the browsers to implement it rather than wait for everyone’s operating system to implement secure dns because that’ll happen .... well I can’t imagine any time in the future you could say everyone’s OS is using crypto DNS, whereas if browsers implement it for themselves, instant massive adoption.
Not sure what any of your reply means. Adding OS support isn’t required. People just run a local resolver that supports these things. No different than any other application. Nothing arcane. Certainly no more than HTTP and SSL.
>> People just run a local resolver that’s support’s these things.
Nowhere do “people just run a local resolver”. Grandma and aunty Beryl certainly don’t, nor does any other ordinary person. If you want secure DNS you have to build it in to the browser.
Only systems people think that this is the sort of thing that ordinary people do.
Not true. In the default case, Grandma's wifi router is just passing along -- via DHCP -- the IP address of the cable company's DNS resolver to Grandma's computer. Which the wifi router itself probably obtained via DHCP or a similar mechanism from the modem. This is in no sense a "local DNS resolver."
If Grandma has a grandchild that knows how to set up a PiHole, it's a different story. But that's certainly not the majority of Grandmas or the majority of wifi routers.
People don’t take issue with DoH, they take issue with an advertising supported browser like Mozilla’s unicast (and now bicast) centralization of DNS traffic that was previously distributed.
We invented DNSCrypt. There’s also DNS over TLS. Lots of ways to encrypt DNS without centralization.
They make this about DoH when really the primary issues are with how they went about it.