4 ms·

Can anyone explain why DoH was invented? To me it seems like another one of the "let's solve this using web technologies!" Whereas DoT has a great ietf process

by bjoli 7y ago

Can anyone explain why DoH was invented? To me it seems like another one of the "let's solve this using web technologies!" Whereas DoT has a great ietf process behind it.

cstejerean 7y ago
My guess is that networks can block the DoT ports to force fallback to plaintext DNS. Whereas DoH looks indistinguishable to HTTPS traffic so it’s harder to block.
tptacek 7y ago
Two primary use cases were considered during this protocol's development. These use cases are preventing on-path devices from interfering with DNS operations, and also allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS). 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).
- kchamplewski 7y ago
  The biggest complaint I have regarding DoH is that it's extremely painful to configure because every application does it individually. 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.
  - tptacek 7y ago
    This seems a lot more like a complaint about your libc than about DoH. But the response to that complaint would likely be "give it time".
  - judge2020 7y ago
    You can do this on Android Pie and newer, but the overall rollout on other systems might be held up due to the potential issues with enterprises not being happy that their DNS systems are no longer working (and that this is probably far from having priority P0).
- bjoli 7y ago
  Blocking the vast majority of DoH services should be pretty easy, just like with regular DNS. I block a lot of DNS servers that aren't my own. Not all of course, but enough to not have any outgoing requests on port 53.
  - tptacek 7y ago
    It's difficult to block in the general case, though, without reterminating TLS.
- pdkl95 7y ago
  > you can point DoH elsewhere 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.
  - tptacek 7y ago
    Running your own recursive resolver on your own machine doesn't address DNS privacy; in fact, it does the opposite, making your DNS lookups even more attributable. Of course, you can run your own resolver on a network somewhere else, and then DoH to it, but then you're just making my point for me.
    - pdkl95 7y ago
      > making your DNS lookups even more attributable That's missing the point. I don't care what a nameserver learns from my DNS request when I'm almost always going to follow that request by opening s socket to the referenced server. The delegated nameserver and the referenced (e.g. HTTP{,S}) server are controlled by the same entity, which is compartmentalized from other unrelated DNS requests when you perform the recursive resolution locally. It seems like you're only considering privacy at the protocol level. While that's important, it can eventually be fixed with improved protocols. I'm far more concerned about de facto standardizing on requiring a centralized service that necessarily has access to the plaintext DNS traffic. The only way to prevent logging of the user's entire internet pattern-of-life is to not give the entire pattern to a single entity. To be clear: we should be updating all plaintext protocols with encryption/etc. Both DoT and DoH can help achieve that goal. Some sort of encrypted protocol is needed even when running a recursive resolver (such as DoT). It would also be great if popular OS had built-in support for running a local recursive resolver, OS-level support for DoH/DoT, and other advanced features.

by bjoli 7y ago

Can anyone explain why DoH was invented? To me it seems like another one of the "let's solve this using web technologies!" Whereas DoT has a great ietf process behind it.

cstejerean 7y ago

My guess is that networks can block the DoT ports to force fallback to plaintext DNS. Whereas DoH looks indistinguishable to HTTPS traffic so it’s harder to block.

tptacek 7y ago

Two primary use cases were considered during this protocol's development. These use cases are preventing on-path devices from interfering with DNS operations, and also allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS). 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).

kchamplewski 7y ago
The biggest complaint I have regarding DoH is that it's extremely painful to configure because every application does it individually. 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.
- tptacek 7y ago
  This seems a lot more like a complaint about your libc than about DoH. But the response to that complaint would likely be "give it time".
- judge2020 7y ago
  You can do this on Android Pie and newer, but the overall rollout on other systems might be held up due to the potential issues with enterprises not being happy that their DNS systems are no longer working (and that this is probably far from having priority P0).
bjoli 7y ago
Blocking the vast majority of DoH services should be pretty easy, just like with regular DNS. I block a lot of DNS servers that aren't my own. Not all of course, but enough to not have any outgoing requests on port 53.
- tptacek 7y ago
  It's difficult to block in the general case, though, without reterminating TLS.
pdkl95 7y ago
> you can point DoH elsewhere 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.
- tptacek 7y ago
  Running your own recursive resolver on your own machine doesn't address DNS privacy; in fact, it does the opposite, making your DNS lookups even more attributable. Of course, you can run your own resolver on a network somewhere else, and then DoH to it, but then you're just making my point for me.
  - pdkl95 7y ago
    > making your DNS lookups even more attributable That's missing the point. I don't care what a nameserver learns from my DNS request when I'm almost always going to follow that request by opening s socket to the referenced server. The delegated nameserver and the referenced (e.g. HTTP{,S}) server are controlled by the same entity, which is compartmentalized from other unrelated DNS requests when you perform the recursive resolution locally. It seems like you're only considering privacy at the protocol level. While that's important, it can eventually be fixed with improved protocols. I'm far more concerned about de facto standardizing on requiring a centralized service that necessarily has access to the plaintext DNS traffic. The only way to prevent logging of the user's entire internet pattern-of-life is to not give the entire pattern to a single entity. To be clear: we should be updating all plaintext protocols with encryption/etc. Both DoT and DoH can help achieve that goal. Some sort of encrypted protocol is needed even when running a recursive resolver (such as DoT). It would also be great if popular OS had built-in support for running a local recursive resolver, OS-level support for DoH/DoT, and other advanced features.