DoT or DoH are supported in Android (9+), iOS (14+), Linux (systemd-resolved, stubby, other resolvers), macOS (11+) and coming to Windows in 2021. So what exactly having separate implementation in apps achieves? That is, except for the possibility of mismatched configuration between such applications and the OS, leading to hard to debug problems?
No DoT is not DoH. They both are blockable; DoH servers must use either well-known IPs, or to be bootstrapped by the plain DNS. First one you can block as well, the second you can filter.
> Of those platforms that do support DoH, how many of them have it on by default, rather than requiring the user to know it exists and turn it on?
Being off by default is a feature. Those road warriors that do not trust their coffee shops can turn it on if they want it, but elsewhere it causes nothing but trouble.
> DoH servers must use either well-known IPs, or to be bootstrapped by the plain DNS.
The easy solution is for the well-kmown IP to be in the same pool that a major CDN uses, so it can't be blocked without major collateral damage.
As for being off by default, that's absolutely not a feature. Basically nobody who's non-technical will ever turn this on, even though it will improve privacy for no downside for most people. What "trouble" does it cause anyway?
> The easy solution is for the well-kmown IP to be in the same pool that a major CDN uses, so it can't be blocked without major collateral damage.
I can imagine that there are players who are OK with that collateral damage. In the end it will end up exactly like when the cloud providers disabled TLS domain fronting.
> even though it will improve privacy for no downside for most people
It won't. The big DoH providers will have nice behavioral data, on computer level, i.e. NAT is no longer a problem, they can distinguish separate device due to TLS session.
Privacy-wise, it is net negative. Few big companies will be getting data they didn't have until now.
> What "trouble" does it cause anyway?
You don't know, so you will use scare quotes then?
It has problems with DNS zones that only some resolvers can resolve, and/or are under ACLs so only local clients can resolve them. Your local network knows about them, the global ones don't.
It has problems with split-horizon names. So now, instead of getting internal IP for a service, you will be getting external one, so your traffic will go to router and back.
It has privacy implications that you didn't even began to think about.
Most networks are not coffeeshop wifi, where such behavior would be OK.
> I can imagine that there are players who are OK with that collateral damage. In the end it will end up exactly like when the cloud providers disabled TLS domain fronting.
The problem with domain fronting was that it could be blocked by blocking the chosen "front" domain, which bad actors were often willing to do. In this new era of eSNI, they'd have to block all of CloudFlare, which would be a lot harder sell even for an entity like China.
> It won't. The big DoH providers will have nice behavioral data, on computer level, i.e. NAT is no longer a problem, they can distinguish separate device due to TLS session.
> Privacy-wise, it is net negative. Few big companies will be getting data they didn't have until now.
I trust CloudFlare more than my ISP with my privacy, and if you don't, then you can pick another DoH server that you do trust.
> It has problems with DNS zones that only some resolvers can resolve, and/or are under ACLs so only local clients can resolve them. Your local network knows about them, the global ones don't.
Firefox will fall back to the local resolver for domains that fail to resolve with DoH.
> It has problems with split-horizon names. So now, instead of getting internal IP for a service, you will be getting external one, so your traffic will go to router and back.
With managed clients, you'd push out configuration to exempt the internal names from DoH. And what's the use case for split-horizon DNS with unmanaged clients? I've never seen that.
> It has privacy implications that you didn't even began to think about.
> The problem with domain fronting was that it could be blocked by blocking the chosen "front" domain, which bad actors were often willing to do. In this new era of eSNI, they'd have to block all of CloudFlare, which would be a lot harder sell even for an entity like China.
Entity like China are willing to block entire subnets if the subnet owner doesn't coooperate and doesn't separate the traffic. That would make the subnet owner's customer nervous, thus them pushing for cooperation in the first place.
> I trust CloudFlare more than my ISP with my privacy, and if you don't, then you can pick another DoH server that you do trust.
The thing is, I don't want to pick one single DoH server. I want to use the resolver that knows the local network, i.e. exactly how DHCP works today. I would be fine if there was a way to announce DoH/DoT via DHCP[1] and all the systems and apps would respect it.
> Firefox will fall back to the local resolver for domains that fail to resolve with DoH.
Just wait until ignorant people will start screaming about "DNS leaks" -- just like they do today with VPNs.
> And what's the use case for split-horizon DNS with unmanaged clients? I've never seen that.
BYODs. There are organizations (both for and non-profit), that have external co-workers, working with their own devices, that are not managed by GPO or MDM.
>> It has privacy implications that you didn't even began to think about.
> Like what?
Centralized service, preconfigured by default, used by many people, capable of discerning browsing habits per device even behind NAT. What could possibly go wrong.
[1] Though it has really no sense in trusted networks; DHCP can announce classic 53/udp service, the resolver can use DoT/DoH for the upstream, and the client would be none the wiser. In fact, many networks do exactly this today.
> Entity like China are willing to block entire subnets if the subnet owner doesn't coooperate and doesn't separate the traffic. That would make the subnet owner's customer nervous, thus them pushing for cooperation in the first place.
Once eSNI is widely deployed, in addition to CloudFlare, DoH could also be ran from anywhere in Azure, AWS, or GCP. At that point, China will have to choose between breaking all TLS, blocking almost all traffic to the US, or accepting DoH leaking.
> The thing is, I don't want to pick one single DoH server. I want to use the resolver that knows the local network, i.e. exactly how DHCP works today. I would be fine if there was a way to announce DoH/DoT via DHCP[1] and all the systems and apps would respect it.
But the network is the main adversary. It would just advertise a DoH server that does censorship or surveillance, and then we're back where we started.
> > Firefox will fall back to the local resolver for domains that fail to resolve with DoH.
> Just wait until ignorant people will start screaming about "DNS leaks" -- just like they do today with VPNs.
That feature is optional. It's easy to turn that off if you don't want it to happen. And even if that weren't the case, isn't most of your DNS requests being safe better than none of them being safe?
> BYODs. There are organizations (both for and non-profit), that have external co-workers, working with their own devices, that are not managed by GPO or MDM.
So just add one step to onboarding: after "here's the Wi-Fi password", it's "here's the subnet to add to the DoH exclusion list".
> Centralized service, preconfigured by default, used by many people, capable of discerning browsing habits per device even behind NAT. What could possibly go wrong.
A lot less that could go wrong with the current state of ISPs.
