7 ms·

This extreme focus on DoH is really concerning me. If you're worried about your recursive DNS resolver spying on you, the correct solution is to run your own r

This extreme focus on DoH is really concerning me. If you're worried about your recursive DNS resolver spying on you, the correct solution is to run your own recursive resolver. I've been running unbound(8) on my OpenBSD systems at home for most of 2019, and (except for the time that I experimented with turning on strict DNSSEC checking) there hasn't been even one time that it has caused me grief. It was as simple as "rcctl enable unbound". And OpenBSD has recently introduced unwind(8), a dead-simple recursive resolver (using libunbound) that's suitable for any system (even laptops that sometimes use broken Wifi access points or networks that block outbound port 53). It is simply unacceptable for a modern operating system to lack its own recursive resolver. By all means, allow the network administrator to configure the system to use a network-provided resolver if required, but the default ought to be an intelligent unwind(8)-style resolver provided by the OS itself.

tptacek 7y ago
Running your own non-DOH recursive server does absolutely nothing to protect your queries from snooping; in fact, it increases your exposure, because every single step in the recursive queries you run are now in plaintext on the wire and each attributable to your server. Running your own recursive DOH server is a fine idea, and easy to do, but then you have little to be angry at Mozilla about, because they're the ones enabling you to do that. The fact that no mainstream consumer OS runs a local recursive resolver should be a clear signal to you that people disagree with you about this; in particular, because doing so eliminates DNS caching, which is something most people want. People are "extremely focused" on DOH because it works, and works without having to secure the cooperation of every DNS operator on the Internet, and with almost no configuration. It is a clean, easy win, unlike every other DNS security mechanism ever proposed.
- zzzcpan 7y ago
  You are saying nonsense. Your own DoH server is the same recursive resolver with queries in plaintext on the wire each attributable to your server by whoever is looking. In fact, if you move your DoH server outside of your home, you are roughly doubling amount of parties involved in looking at your metadata, because pretty much none of the metadata is hidden when you just remove DNS queries from your wire and replace it with TLS, but now a whole set of other parties get to see your queries and your TLS connection towards your DoH server with identifiable IP address, likely even recorded and stored for years by more parties. There are no "wins" with DoH no matter how you look at it.
  - strbean 7y ago
    You could host your DoH server somewhere and use a different IP for inbound vs. outbound requests. Then the only point of failure is the cloud host, no?
  - tptacek 7y ago
    The whole point of DoH is that you don't run the DoH recursive cache on the network you don't trust. Before you use words like "nonsense", you should spend some time understanding what DoH is.
    - zzzcpan 7y ago
      > The whole point of DoH is that you don't run the DoH recursive cache on the network you don't trust. Nope. There is no point to DoH and you can't actually run "DoH recursive cache" within trusted network, because it communicates with authoritative servers over public internet.
      - tptacek 7y ago
        You still don't get it. The threat model of DoH is your local ISP. The mitigation is to move DNS off your untrusted local ISP to a network you trust more. To the extent it's not cached, if you have a shared DoH resolver, yes, the DNS queries you're generating are eventually sent in plaintext. But they're sent in plaintext over a network you trust more than your ISP's. DoH is essentially a DNS-only VPN. It has exactly the security model of a VPN with respect to the DNS protocol. The attack DoH breaks immediately is your US mainstream ISP recording all your DNS queries, which is something that is happening today. I really don't understand how people rationalize around this. It's not an exotic attack, like the cache-corruption attacks DNSSEC attempts to defend against; it's something that's happening constantly, all day, every day.
        zzzcpan 7y ago
        > The threat model of DoH is your local ISP. There is no threat model for DoH, only ad hoc attempts to justify it. Here's the thing, your ISP sees all of your packets with all the IP addresses and ports and payload size and the exact time they were sent and received. This identifies every website you visited with very high accuracy, I mean just IP addresses alone identify more than 90% of the websites you visited. > DoH is essentially a DNS-only VPN. It has exactly the security model of a VPN with respect to the DNS protocol. That "security model" is just integrity in communications with resolver, but it actually sacrifices privacy for that. > The attack DoH breaks immediately is your US mainstream ISP recording all your DNS queries This is absolutely useless "attack" to break. Most ISPs in the world record netflow-like data and store it for a long time, which provides more detailed profile on you, than DNS queries. If they store DNS queries, those are just for commercialization, not for snooping.
- zrm 7y ago
  > The fact that no mainstream consumer OS runs a local recursive resolver should be a clear signal to you that people disagree with you about this; in particular, because doing so eliminates DNS caching, which is something most people want. Doesn't DoH eliminate caching as well? It means all your queries go out to some server on the internet with perhaps 20-50ms of latency, instead of a local cache potentially on your LAN with <1ms. A DNS cache on the LAN would also merge queries from multiple devices, concealing which device is making the query and in many cases preventing the query from having to be sent over the internet at all. The best thing might be to have internet gateways run a DNS stub that itself makes queries via DoH/DoT/whatever and then caches them for every device on the LAN. The gateway is typically the DHCP server so it can hand itself out as the DNS and requires no configuration as well. And then it works across all devices and applications.
  - deleted 7y ago
    [deleted]
  - pvg 7y ago
    Doesn't DoH eliminate caching as well? Why would it eliminate caching? If you resolve over DoH you can still cache. It's not like turning DoH on in FireFox forces it to stop caching.
    - zrm 7y ago
      In that sense neither would putting a recursive resolver in your OS. DNS can have arbitrarily many levels of caching, because stub resolvers can be caches and can point to other stub resolvers. For example, you might have a DNS cache in your OS so that if more than one process asks to resolve the same name (or the same process asks more than once because it doesn't have internal caching), only one query has to be made. That resolver may point to a DNS cache on your LAN (deduplicating queries between devices), which in turn may point to a recursive resolver on the internet, which may itself be caching data from the authoritative servers. If you replace that with DoH between the application and the recursive resolver on the internet, all the intermediary caches are eliminated, even though they might have had significantly lower response times than the resolver on the internet.
- kiwidrew 7y ago
  Running a recursive resolver does protect against one very specific kind of threat: a malicious recursive resolver that has decided to log all of my queries. DoH absolutely does not protect against this specific threat, because it's just a different protocol for speaking to a third-party recursive resolver. A properly-configured resolver (i.e. one that is doing QNAME minimisation) only reveals a very limited amount of information to each DNS server that it queries. It's akin to the fact that browsing a web site reveals my activity to that site's origin server. I'm not overly concerned about it. The only threat that DoH protects against is the situation where an adversary is able to observe all of my outbound DNS query traffic. In this very specific scenario (essentially a compromised ISP), then yes, DoH offers better privacy protection. But it's a rather Faustian bargain to make, because in order to receive protection against a malicious ISP, I must instead put my full trust in whomever is operating the DoH resolver. Out of the kettle and into the frying pan, isn't it? So DoH doesn't solve the problem. It merely lets users transfer their trust from their ISP (with whom they have a legal contractual relationship governed under the laws of their home country) to a large third-party organisation (with whom they do not have a legal contractual relationship). If it came down to a matter of holding someone to account for a breach of my privacy, I'd sure rather be up against my local ISP as opposed to a faceless global entity such as Google, Cloudflare, or even the Mozilla Foundation.
- asveikau 7y ago
  > no mainstream consumer OS runs a local recursive resolver I think Windows might do something close. DNS client requests are cached on a per-machine basis through the DnsCache NT service. But I do not think getaddrinfo() and friends talk to that service via DNS, so strictly speaking it is not a recursive DNS server, though the resulting behavior is largely the same as if it were.
  - akerl_ 7y ago
    I think there’s a differentiation here between a local DNS cache (which does exist on some consumer operating systems) and a local recursive resolver. The former lets the system reach out to an upstream resolver and caches the results. By contrast, a recursive resolver is responsible for starting at the root zone and recursing downward from there to resolve the requested domain (so when processing a query for “foo.example.org”, the recursive resolver queries “org”, then uses the NS records returned to query “org.example”, then uses the returned NS records to query “org.example.foo”)
    - asveikau 7y ago
      Yeah ok, that's a difference I hadn't thought of. In most local caching servers the next hop is going to be the ISP or similar, rather than going to the root.
e12e 7y ago
Hm, looks like unwind just falls back to letting the local recursive resolver spy on you in case port 53 is blocked, though? I guess it + local recursive resolver between them might have bit of a cache - but the browser could also cache dns more aggressively (not that I think that'd be a good idea). Not saying it's bad to run unwind, just that if the scenario is that the router blocks access to root servers, and the local resolver spys on you - it (alone) won't help? And with a spying local resolver, I'd assume the router logs plain text udp traffic anyway... https://man.openbsd.org/unwind.8 https://man.openbsd.org/unwind.8
3xblah 7y ago
If the user is sitting behind a filtered port 53, e.g., at a hotel, running her own resolver will not solve the problem. This filtering of port 53 may be growing in popularity among ISPs. If it is, then that means users cannot easily choose their own source of DNS data. It becomes necessary to connect to some remote computer you control that can send traffic on port 53 just to send an authoritative DNS query. It is like having to pay two ISPs now instead of one. What are the "free" workarounds. There are free-trial DNS "relocator" services and DNSCrypt resolvers running on ports other than 53 (I am not aware of any authoritative servers running behind dnscrypt-wrapper). Now there are also "DOH servers" running on port 443, serving resolver responses via HTTP. One unique feature of DOH -- for those doing bulk lookups -- is that one can query multiple names with a single packet. That is not possible using the DNS protocol. For folks who are stuck with port 53 filtering, as a temporary solution, I would like to see more remote DNS servers, both recursive and authoritative, running on ports other than 53. They do not have to be "relocator" services, encrypted or served via HTTP. They just need to use ports other than 53. Then, when running a local resolver, the user can set it to forward queries to a remote one listening on a non-standard port or she can query authoritative servers directly, e.g., root or .com servers, using stub resolvers. It is every internet user's right to be able to query the authoritative servers for a domain's IP address -- whether from her own local resolver or from a stub, the same way it is to request access to a public zone file. Filtering port 53 is unacceptable. Otherwise, we are allowing third parties to become the absolute gatekeepers to the sources of authority for finding an IP address. Caches are not authoritative sources of DNS data.
- kiwidrew 7y ago
  > Otherwise, we are allowing third parties to become the absolute gatekeepers to the sources of authority for finding an IP address. Caches are not authoritative sources of DNS data. In theory this is what DNSSEC is meant to provide: cryptographic proof that the cache is giving you unmodified data from the zone's authoritative server(s). Unfortunately... it's still very difficult to run a recursive resolver in a "hardened" configuration that strictly enforces DNSSEC validity, and that's without having a potentially-malicious cache in your query path. The reality is that most networks blocking port 53 are also entirely unaware of DNSSEC, and in such a situation there's really no hope aside from a full-fledged VPN -- or DoH. So I think DoH absolutely does have some use cases, such as clients using broken hotel/conference networks and laptops that are temporarily using insecure public WiFi access points. But it doesn't belong anywhere near my own, properly-configured home and work networks.

tptacek 7y ago

Running your own non-DOH recursive server does absolutely nothing to protect your queries from snooping; in fact, it increases your exposure, because every single step in the recursive queries you run are now in plaintext on the wire and each attributable to your server. Running your own recursive DOH server is a fine idea, and easy to do, but then you have little to be angry at Mozilla about, because they're the ones enabling you to do that. The fact that no mainstream consumer OS runs a local recursive resolver should be a clear signal to you that people disagree with you about this; in particular, because doing so eliminates DNS caching, which is something most people want. People are "extremely focused" on DOH because it works, and works without having to secure the cooperation of every DNS operator on the Internet, and with almost no configuration. It is a clean, easy win, unlike every other DNS security mechanism ever proposed.

zzzcpan 7y ago
You are saying nonsense. Your own DoH server is the same recursive resolver with queries in plaintext on the wire each attributable to your server by whoever is looking. In fact, if you move your DoH server outside of your home, you are roughly doubling amount of parties involved in looking at your metadata, because pretty much none of the metadata is hidden when you just remove DNS queries from your wire and replace it with TLS, but now a whole set of other parties get to see your queries and your TLS connection towards your DoH server with identifiable IP address, likely even recorded and stored for years by more parties. There are no "wins" with DoH no matter how you look at it.
- strbean 7y ago
  You could host your DoH server somewhere and use a different IP for inbound vs. outbound requests. Then the only point of failure is the cloud host, no?
- tptacek 7y ago
  The whole point of DoH is that you don't run the DoH recursive cache on the network you don't trust. Before you use words like "nonsense", you should spend some time understanding what DoH is.
  - zzzcpan 7y ago
    > The whole point of DoH is that you don't run the DoH recursive cache on the network you don't trust. Nope. There is no point to DoH and you can't actually run "DoH recursive cache" within trusted network, because it communicates with authoritative servers over public internet.
    - tptacek 7y ago
      You still don't get it. The threat model of DoH is your local ISP. The mitigation is to move DNS off your untrusted local ISP to a network you trust more. To the extent it's not cached, if you have a shared DoH resolver, yes, the DNS queries you're generating are eventually sent in plaintext. But they're sent in plaintext over a network you trust more than your ISP's. DoH is essentially a DNS-only VPN. It has exactly the security model of a VPN with respect to the DNS protocol. The attack DoH breaks immediately is your US mainstream ISP recording all your DNS queries, which is something that is happening today. I really don't understand how people rationalize around this. It's not an exotic attack, like the cache-corruption attacks DNSSEC attempts to defend against; it's something that's happening constantly, all day, every day.
      - zzzcpan 7y ago
        > The threat model of DoH is your local ISP. There is no threat model for DoH, only ad hoc attempts to justify it. Here's the thing, your ISP sees all of your packets with all the IP addresses and ports and payload size and the exact time they were sent and received. This identifies every website you visited with very high accuracy, I mean just IP addresses alone identify more than 90% of the websites you visited. > DoH is essentially a DNS-only VPN. It has exactly the security model of a VPN with respect to the DNS protocol. That "security model" is just integrity in communications with resolver, but it actually sacrifices privacy for that. > The attack DoH breaks immediately is your US mainstream ISP recording all your DNS queries This is absolutely useless "attack" to break. Most ISPs in the world record netflow-like data and store it for a long time, which provides more detailed profile on you, than DNS queries. If they store DNS queries, those are just for commercialization, not for snooping.
zrm 7y ago
> The fact that no mainstream consumer OS runs a local recursive resolver should be a clear signal to you that people disagree with you about this; in particular, because doing so eliminates DNS caching, which is something most people want. Doesn't DoH eliminate caching as well? It means all your queries go out to some server on the internet with perhaps 20-50ms of latency, instead of a local cache potentially on your LAN with <1ms. A DNS cache on the LAN would also merge queries from multiple devices, concealing which device is making the query and in many cases preventing the query from having to be sent over the internet at all. The best thing might be to have internet gateways run a DNS stub that itself makes queries via DoH/DoT/whatever and then caches them for every device on the LAN. The gateway is typically the DHCP server so it can hand itself out as the DNS and requires no configuration as well. And then it works across all devices and applications.
- deleted 7y ago
  [deleted]
- pvg 7y ago
  Doesn't DoH eliminate caching as well? Why would it eliminate caching? If you resolve over DoH you can still cache. It's not like turning DoH on in FireFox forces it to stop caching.
  - zrm 7y ago
    In that sense neither would putting a recursive resolver in your OS. DNS can have arbitrarily many levels of caching, because stub resolvers can be caches and can point to other stub resolvers. For example, you might have a DNS cache in your OS so that if more than one process asks to resolve the same name (or the same process asks more than once because it doesn't have internal caching), only one query has to be made. That resolver may point to a DNS cache on your LAN (deduplicating queries between devices), which in turn may point to a recursive resolver on the internet, which may itself be caching data from the authoritative servers. If you replace that with DoH between the application and the recursive resolver on the internet, all the intermediary caches are eliminated, even though they might have had significantly lower response times than the resolver on the internet.
kiwidrew 7y ago
Running a recursive resolver does protect against one very specific kind of threat: a malicious recursive resolver that has decided to log all of my queries. DoH absolutely does not protect against this specific threat, because it's just a different protocol for speaking to a third-party recursive resolver. A properly-configured resolver (i.e. one that is doing QNAME minimisation) only reveals a very limited amount of information to each DNS server that it queries. It's akin to the fact that browsing a web site reveals my activity to that site's origin server. I'm not overly concerned about it. The only threat that DoH protects against is the situation where an adversary is able to observe all of my outbound DNS query traffic. In this very specific scenario (essentially a compromised ISP), then yes, DoH offers better privacy protection. But it's a rather Faustian bargain to make, because in order to receive protection against a malicious ISP, I must instead put my full trust in whomever is operating the DoH resolver. Out of the kettle and into the frying pan, isn't it? So DoH doesn't solve the problem. It merely lets users transfer their trust from their ISP (with whom they have a legal contractual relationship governed under the laws of their home country) to a large third-party organisation (with whom they do not have a legal contractual relationship). If it came down to a matter of holding someone to account for a breach of my privacy, I'd sure rather be up against my local ISP as opposed to a faceless global entity such as Google, Cloudflare, or even the Mozilla Foundation.
asveikau 7y ago
> no mainstream consumer OS runs a local recursive resolver I think Windows might do something close. DNS client requests are cached on a per-machine basis through the DnsCache NT service. But I do not think getaddrinfo() and friends talk to that service via DNS, so strictly speaking it is not a recursive DNS server, though the resulting behavior is largely the same as if it were.
- akerl_ 7y ago
  I think there’s a differentiation here between a local DNS cache (which does exist on some consumer operating systems) and a local recursive resolver. The former lets the system reach out to an upstream resolver and caches the results. By contrast, a recursive resolver is responsible for starting at the root zone and recursing downward from there to resolve the requested domain (so when processing a query for “foo.example.org”, the recursive resolver queries “org”, then uses the NS records returned to query “org.example”, then uses the returned NS records to query “org.example.foo”)
  - asveikau 7y ago
    Yeah ok, that's a difference I hadn't thought of. In most local caching servers the next hop is going to be the ISP or similar, rather than going to the root.

e12e 7y ago

Hm, looks like unwind just falls back to letting the local recursive resolver spy on you in case port 53 is blocked, though? I guess it + local recursive resolver between them might have bit of a cache - but the browser could also cache dns more aggressively (not that I think that'd be a good idea). Not saying it's bad to run unwind, just that if the scenario is that the router blocks access to root servers, and the local resolver spys on you - it (alone) won't help? And with a spying local resolver, I'd assume the router logs plain text udp traffic anyway... https://man.openbsd.org/unwind.8 https://man.openbsd.org/unwind.8

3xblah 7y ago

If the user is sitting behind a filtered port 53, e.g., at a hotel, running her own resolver will not solve the problem. This filtering of port 53 may be growing in popularity among ISPs. If it is, then that means users cannot easily choose their own source of DNS data. It becomes necessary to connect to some remote computer you control that can send traffic on port 53 just to send an authoritative DNS query. It is like having to pay two ISPs now instead of one. What are the "free" workarounds. There are free-trial DNS "relocator" services and DNSCrypt resolvers running on ports other than 53 (I am not aware of any authoritative servers running behind dnscrypt-wrapper). Now there are also "DOH servers" running on port 443, serving resolver responses via HTTP. One unique feature of DOH -- for those doing bulk lookups -- is that one can query multiple names with a single packet. That is not possible using the DNS protocol. For folks who are stuck with port 53 filtering, as a temporary solution, I would like to see more remote DNS servers, both recursive and authoritative, running on ports other than 53. They do not have to be "relocator" services, encrypted or served via HTTP. They just need to use ports other than 53. Then, when running a local resolver, the user can set it to forward queries to a remote one listening on a non-standard port or she can query authoritative servers directly, e.g., root or .com servers, using stub resolvers. It is every internet user's right to be able to query the authoritative servers for a domain's IP address -- whether from her own local resolver or from a stub, the same way it is to request access to a public zone file. Filtering port 53 is unacceptable. Otherwise, we are allowing third parties to become the absolute gatekeepers to the sources of authority for finding an IP address. Caches are not authoritative sources of DNS data.

kiwidrew 7y ago
> Otherwise, we are allowing third parties to become the absolute gatekeepers to the sources of authority for finding an IP address. Caches are not authoritative sources of DNS data. In theory this is what DNSSEC is meant to provide: cryptographic proof that the cache is giving you unmodified data from the zone's authoritative server(s). Unfortunately... it's still very difficult to run a recursive resolver in a "hardened" configuration that strictly enforces DNSSEC validity, and that's without having a potentially-malicious cache in your query path. The reality is that most networks blocking port 53 are also entirely unaware of DNSSEC, and in such a situation there's really no hope aside from a full-fledged VPN -- or DoH. So I think DoH absolutely does have some use cases, such as clients using broken hotel/conference networks and laptops that are temporarily using insecure public WiFi access points. But it doesn't belong anywhere near my own, properly-configured home and work networks.