3 ms·

> 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 t

by 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.
  - tptacek 7y ago
    DoH is the improved protocol. There's nothing "centralized" about it; you can run a DoH cache server anywhere you want. The only reason anyone advocates DoT is because network operators can block it, forcing people to use plaintext DNS. Somehow, the meme has been created that DoT is somehow better or more privacy-respecting than DoH, but that's obviously false.
    - pdkl95 7y ago
      > DoH is the improved protocol. That doesn't appear to be true, according to RFC 8484. DoH cannot be used for encrypting communication to domain-delegated nameservers. Running your own DoH server just moves the problem to a different host. If I run a DoH server locally as a recursive resolver, the encryption between the browser and the DoH server is useless. The DoH server still sends the requests to domain-delegated nameservers in plaintext. The protocol is explicitly[1] focused: on communication between DNS clients (such as operating system stub resolvers) and recursive resolvers. The RFC doesn't provide any method to discover the "URI Template" of a domain's authoritative DoH server. The existing NS records only[2] include a domain name. This omitted feature appears to be intentional; RFC 8484 only says[3] that configuration of the "URI Template": might be manual (such as a user typing URI Templates in a user interface for "options") or automatic (such as URI Templates being supplied in responses from DHCP or similar protocols). Even worse, the protocol seems to require[3] aggregating all requests through a single DoH server: A DoH client MUST NOT use a different URI simply because it was discovered outside of the client's configuration That seems to forbid the fundamental idea of discovering delegated nameservers. Why would a core feature of DNS be forbidden? Apparently from a concern[3] that allowing unrecognized URIs: may create additional operational, tracking, and security hazards that require limitations for safe usage. This is a strange concern. If the user wants to perform a DNS request, that's their business. How would this become a "tracking [or] security hazard"? This concern seems to be a consequence of a design goal for DoH: Two primary use cases were considered during this protocol's development. These use cases are [...] allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS) DoH is designed to enable performing DNS requests in a web app (which will probably be yet another API I will need to disable). If I'm mistaken and it is possible to use DoH in a recursive resolver, how would that work? > There's nothing "centralized" about it Requiring that a client "MUST NOT use a different URI" is the very definition of a "centralized" protocol. Moving to DoH from my existing local recursive resolver would be a huge loss of privacy. If there a way DoH can compartmentalize DNS requests to the domain specific nameservers, I would like to know how. [1] https://tools.ietf.org/html/rfc8484#section-1 https://tools.ietf.org/html/rfc8484#section-1 [2] https://tools.ietf.org/html/rfc1035#section-3.3.11 https://tools.ietf.org/html/rfc1035#section-3.3.11 [3] https://tools.ietf.org/html/rfc8484#section-3 https://tools.ietf.org/html/rfc8484#section-3

by pdkl95 7y ago

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.
- tptacek 7y ago
  DoH is the improved protocol. There's nothing "centralized" about it; you can run a DoH cache server anywhere you want. The only reason anyone advocates DoT is because network operators can block it, forcing people to use plaintext DNS. Somehow, the meme has been created that DoT is somehow better or more privacy-respecting than DoH, but that's obviously false.
  - pdkl95 7y ago
    > DoH is the improved protocol. That doesn't appear to be true, according to RFC 8484. DoH cannot be used for encrypting communication to domain-delegated nameservers. Running your own DoH server just moves the problem to a different host. If I run a DoH server locally as a recursive resolver, the encryption between the browser and the DoH server is useless. The DoH server still sends the requests to domain-delegated nameservers in plaintext. The protocol is explicitly[1] focused: on communication between DNS clients (such as operating system stub resolvers) and recursive resolvers. The RFC doesn't provide any method to discover the "URI Template" of a domain's authoritative DoH server. The existing NS records only[2] include a domain name. This omitted feature appears to be intentional; RFC 8484 only says[3] that configuration of the "URI Template": might be manual (such as a user typing URI Templates in a user interface for "options") or automatic (such as URI Templates being supplied in responses from DHCP or similar protocols). Even worse, the protocol seems to require[3] aggregating all requests through a single DoH server: A DoH client MUST NOT use a different URI simply because it was discovered outside of the client's configuration That seems to forbid the fundamental idea of discovering delegated nameservers. Why would a core feature of DNS be forbidden? Apparently from a concern[3] that allowing unrecognized URIs: may create additional operational, tracking, and security hazards that require limitations for safe usage. This is a strange concern. If the user wants to perform a DNS request, that's their business. How would this become a "tracking [or] security hazard"? This concern seems to be a consequence of a design goal for DoH: Two primary use cases were considered during this protocol's development. These use cases are [...] allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS) DoH is designed to enable performing DNS requests in a web app (which will probably be yet another API I will need to disable). If I'm mistaken and it is possible to use DoH in a recursive resolver, how would that work? > There's nothing "centralized" about it Requiring that a client "MUST NOT use a different URI" is the very definition of a "centralized" protocol. Moving to DoH from my existing local recursive resolver would be a huge loss of privacy. If there a way DoH can compartmentalize DNS requests to the domain specific nameservers, I would like to know how. [1] https://tools.ietf.org/html/rfc8484#section-1 https://tools.ietf.org/html/rfc8484#section-1 [2] https://tools.ietf.org/html/rfc1035#section-3.3.11 https://tools.ietf.org/html/rfc1035#section-3.3.11 [3] https://tools.ietf.org/html/rfc8484#section-3 https://tools.ietf.org/html/rfc8484#section-3