4 ms·

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 exact

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?

josephcsible 6y ago
DoT is not DoH. Since it uses its own protocol and port, it's easy for networks that want to do censorship or surveillance to block it. 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?
- vetinari 6y ago
  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.
  - josephcsible 6y ago
    > 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?
    - vetinari 6y ago
      > 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.
      - josephcsible 6y ago
        > 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. Like what?

josephcsible 6y ago

DoT is not DoH. Since it uses its own protocol and port, it's easy for networks that want to do censorship or surveillance to block it. 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?

vetinari 6y ago
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.
- josephcsible 6y ago
  > 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?
  - vetinari 6y ago
    > 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.
    - josephcsible 6y ago
      > 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. Like what?