5 ms·

> There is an assumption by many that DNS encryption requires DNS centralization. A lot of the discussion recently, like this statement, conflates "DNS encrypt

by pdkl95 7y ago

> There is an assumption by many that DNS encryption requires DNS centralization. A lot of the discussion recently, like this statement, conflates "DNS encryption" with "DoH". Encrypting DNS does not require centralization, but DoH does require[1] centralization in in the RFC. DoH doesn't even "improve user privacy"; it simply changes who can record your DNS queries. Instead of the ISP, Cloudflare/Microsoft/etc gets to see your unencrypted DNS queries. The way to actually improve privacy is to perform the recursive resolution locally[2]. The actual communication with each individual DNS server needs to be encrypted, which is where work needs to be done. DNS servers need to support DNS over TLS (DoT) or some other type of encrypted transport. Hypothetically, DoH could be modified to support this, although that seems more complicated than simply wrapping the DNS protocol in TLS. You don't get privacy by centralizing all of your requests onto one server. To protect privacy, you limit the data that any one party can see. DNS was designed for this purpose: only the NS record of a domain needs to be sent to a centralized server, which is easy to cache for a long time. Most requests then go to domain-specified authoritative server[4]. It's good to see Microsoft at least trying to address this at the OS level. App doing DNS without involving the OS seems to be more about taking away control from the user. I'm sure Google would love to be able top bypass DNS based adblocking. [1] https://news.ycombinator.com/item?id=21110296 https://news.ycombinator.com/item?id=21110296 [2] Which is easy: follow NS records until you get to the server that has your authoritative answer. [3] https://news.ycombinator.com/item?id=21348328 https://news.ycombinator.com/item?id=21348328

Someone1234 7y ago
> Encrypting DNS does not require centralization, but DoH does require centralization in in the RFC. This isn't a problem that DoH was designed to solve. It is designed to be a highly compatible, secure, endpoint DNS solution. Which it is. So while this criticism is accurate, it is also irrelevant, DoH replaces one "hop" on DNS and that's all it was ever designed to do. > DoH doesn't even "improve user privacy"; it simply changes who can record your DNS queries. I It stops passive eavesdropping. Right now you can change who you use for DNS and your ISP can still monitor your DNS to profile you and invade your privacy. With DoH you can pick a privacy focused endpoint and nobody between you or that endpoint can trivially monitor your DNS. DoT solves this too but has issues (see next response). > DNS servers need to support DNS over TLS (DoT) or some other type of encrypted transport. DoT and even unencrypted DNS is blocked on a lot of free WiFi. Now what? DoH solves this issue, as it was designed to. DoH can traverse even the most locked down network over the same HTTPS channel as any other web traffic. > You don't get privacy by centralizing all of your requests onto one server. Perhaps, but it scales really well and is the basis for all current DNS resolution. If everyone on the internet did as you suggested core internet infrastructure would fail under the load. You've essentially killed almost all caching.
- deleted 7y ago
  [deleted]
- acqq 7y ago
  > With DoH you can pick a privacy focused endpoint and nobody between you or that endpoint can trivially monitor your DNS. Even with the DoH which site you access is still trivially to track by your ISP and anybody along the wire as the site name is still not encrypted in the TLS connection traffic.
  - Someone1234 7y ago
    > site name is still not encrypted in the TLS connection traffic Encrypted SNI is solves exactly that and is becoming increasingly common. None of these solutions work individually to solve privacy problems but all of them together are substantially increasing the cost and decreasing the accuracy of profiling users on-mass. DoT never gained widespread adoption as an endpoint solution due to compatibility problems. It is technically the superior choice (Vs. DoH), but what good is superior if it breaks all the time? DoH is more imperfect but actually works reliably across different network configurations and client devices, which means it "wins" even if it is "worse."
    - acqq 7y ago
      > Encrypted SNI is solves exactly that and is becoming increasingly common. Can you please elaborate? I know only this: https://serverfault.com/questions/976377/how-can-i-set-up-encrypted-sni-on-my-own-servers https://serverfault.com/questions/976377/how-can-i-set-up-en... "Encrypted Server Name Indication (ESNI) is still an Internet Draft, you will not find it in any major server implementation as it is subject to change. In fact, the draft version implemented by Firefox supports draft-ietf-tls-esni-01 which is incompatible with newer draft versions." Edit: I see Firefox Nightly is mentioned, it is the version that normal users who use Firefox (Firefox has at the moment less than 5% worldwide marker share) just don't use (it annoyingly updates every night).
      - Someone1234 7y ago
akvadrako 7y ago
Running your own recursive resolver at home isn't the solution, because it reveals to eavesdroppers what DNS servers you're talking to and it reveals to DNS operators what your IP is. Maybe it's the best current compromise, but it would be better to have a shared and trusted remote recursive resolver which many people talk to.
- penagwin 7y ago
  A Shared and trusted resolver is just centralization again though... I don’t know enough about DNS, but I’m wondering if we could somehow fit BitTorrent into the mix for the home resolver?
- pdkl95 7y ago
  > it reveals to eavesdroppers what DNS servers you're talking to Yes, they (probably the ISP) can do traffic analysis - which is a significant risk - but they are prevented from learning the contents fo the query which puts a limit on what they can learn. Also, the same eavesdroppers can see the TCP connection to the HTTPS server that follows he DNS request. Also, I should have mentioned that while performing recursive resolution locally does provide some actual privacy protections, it is not perfect. Name resolution as a distributed database fundamentally requires leaking some information to the servers that have the information. As long as we resolve names with anything similar to existing DNS, the best we can do is try to limit the damage to privacy. In a perfect world, we would probably use something similar to TOR to perform name resolution. Lots of inputs that onion-route queries to the actual nameservers. > it reveals to DNS operators what your IP is. Revealing my IP to ns.example.com is redundant when I'm almost certainly following the DNS request with a connection to www.example.com; the authoritative server for a domain is controlled (directly or indirectly) by the same org that controls the domain's HTTPS/etc servers.
- blattimwind 7y ago
  For almost every service this genuinely doesn't matter, becasue the authorative DNS server for a given domain will most likely be run by the same entity that runs the server you want to talk to. I wanna point out that a recursive resolver normally caches everything it is allowed to cache, so visting the same site a few times will not, in general, produce any extra DNS requests.
basch 7y ago
You could use k-Anonymity to request a handful of results, without the dns server knowing which result you were looking for. hash the hostname, return all results that have the same x letters as the beginning of the hash. at no point, would the actual site you are requesting leave your lan. your dns resolver would know within 1/400th (how every many results it replies with) which site you were asking for. After time, and recording patterns, they might be able to make educated guesses of which site you were requesting, but it would not be concrete evidence. https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/ https://blog.cloudflare.com/validating-leaked-passwords-with...
- singron 7y ago
  k-Anonymity doesn't really work with non-uniform distributions. E.g. if x is your hash prefix and d is a particular domain that matches that prefix, then we can apply Bayes rule: P(d|x) = P(x|d) * P(d) / P(x) P(x|d) is 1 in this case (the hash is deterministic), so the probability is just P(d)/P(x). E.g. if "facebook.com" doesn't have a hash collision with another similarly popular site, then you can be pretty sure that a request for hash("facebook.com") is a request for "facebook.com" for a high proportion of requests. This also adds some overhead. E.g. 400 IPs+TTLs probably wouldn't fit in a 1500 MTU packet, so it might have to be split up or k reduced to fit. From the ISP perspective, they can also tell which of the k you were interested in because you will probably send a SYN packet to that IP address. Unless you also send 400 SYN packets...
snarf21 7y ago
I understand the approaches of DoT and DoH but people keep talking about privacy and tracking but it just seems like you can just run your own un-DNS server and get the same info by looking up the IP to get the DNS. You can still be monitored and controlled by IP, right?
- JohnFen 7y ago
  Sorta. Not all IP addresses have a domain name associated with them. And if malicious software is actually using raw IP addresses rather than domain names, that makes it easier to stop them because you could just block those IP addresses. This is why that approach is rarely taken -- with domain names, if the IP address is blocked, you can just associate the domain name with a different one.
  - ryanhallinger 7y ago
    If malware are already utilizing channels such as Youtube, the ability to block Google will be exponentially more difficult than attempt to cycle through domains.
heavyset_go 7y ago
> I'm sure Google would love to be able top bypass DNS based adblocking. Google already does this with their Chromecast line of products. Chromecasts will not adhere to your network's DNS servers, and will use Google's DNS servers. Chromecasts will fail to work at all if they cannot communicate with Google's DNS servers. If you try to redirect DNS traffic to the DNS servers of your choice, Chromecasts will not function. They won't work if you block Google's DNS servers, and you cannot change the DNS settings on the device itself.
- goguy 7y ago
  Source? I have a Chromecast which works fine, Google DNS servers are blocked on my network.
  - throw0101a 7y ago
    Paul Vixie experienced chromecast ultra not using DHCP-supplied values: * https://mailarchive.ietf.org/arch/msg/dnsop/WCVv57IizUSjNb2RQNP84fBclI0 https://mailarchive.ietf.org/arch/msg/dnsop/WCVv57IizUSjNb2R... * https://news.ycombinator.com/item?id=19170671 https://news.ycombinator.com/item?id=19170671
tptacek 7y ago
DoH does not require centralization; rather, your linked argument redefines the term to include DNS servers that end-users run for themselves (they're "centralized" I suppose compared to a blockchain protocol?), which it obviously has to, because DoH obviously supports configurations where you run your own DoH resolvers that never speak to Cloud Flare.
ryan_hallinger 7y ago
Hi pdkl95, I would be keen to discuss the topic further with you. What's the best way to connect?

by pdkl95 7y ago

Someone1234 7y ago

> Encrypting DNS does not require centralization, but DoH does require centralization in in the RFC. This isn't a problem that DoH was designed to solve. It is designed to be a highly compatible, secure, endpoint DNS solution. Which it is. So while this criticism is accurate, it is also irrelevant, DoH replaces one "hop" on DNS and that's all it was ever designed to do. > DoH doesn't even "improve user privacy"; it simply changes who can record your DNS queries. I It stops passive eavesdropping. Right now you can change who you use for DNS and your ISP can still monitor your DNS to profile you and invade your privacy. With DoH you can pick a privacy focused endpoint and nobody between you or that endpoint can trivially monitor your DNS. DoT solves this too but has issues (see next response). > DNS servers need to support DNS over TLS (DoT) or some other type of encrypted transport. DoT and even unencrypted DNS is blocked on a lot of free WiFi. Now what? DoH solves this issue, as it was designed to. DoH can traverse even the most locked down network over the same HTTPS channel as any other web traffic. > You don't get privacy by centralizing all of your requests onto one server. Perhaps, but it scales really well and is the basis for all current DNS resolution. If everyone on the internet did as you suggested core internet infrastructure would fail under the load. You've essentially killed almost all caching.

deleted 7y ago
[deleted]
acqq 7y ago
> With DoH you can pick a privacy focused endpoint and nobody between you or that endpoint can trivially monitor your DNS. Even with the DoH which site you access is still trivially to track by your ISP and anybody along the wire as the site name is still not encrypted in the TLS connection traffic.
- Someone1234 7y ago
  > site name is still not encrypted in the TLS connection traffic Encrypted SNI is solves exactly that and is becoming increasingly common. None of these solutions work individually to solve privacy problems but all of them together are substantially increasing the cost and decreasing the accuracy of profiling users on-mass. DoT never gained widespread adoption as an endpoint solution due to compatibility problems. It is technically the superior choice (Vs. DoH), but what good is superior if it breaks all the time? DoH is more imperfect but actually works reliably across different network configurations and client devices, which means it "wins" even if it is "worse."
  - acqq 7y ago
    > Encrypted SNI is solves exactly that and is becoming increasingly common. Can you please elaborate? I know only this: https://serverfault.com/questions/976377/how-can-i-set-up-encrypted-sni-on-my-own-servers https://serverfault.com/questions/976377/how-can-i-set-up-en... "Encrypted Server Name Indication (ESNI) is still an Internet Draft, you will not find it in any major server implementation as it is subject to change. In fact, the draft version implemented by Firefox supports draft-ietf-tls-esni-01 which is incompatible with newer draft versions." Edit: I see Firefox Nightly is mentioned, it is the version that normal users who use Firefox (Firefox has at the moment less than 5% worldwide marker share) just don't use (it annoyingly updates every night).
    - Someone1234 7y ago

akvadrako 7y ago

Running your own recursive resolver at home isn't the solution, because it reveals to eavesdroppers what DNS servers you're talking to and it reveals to DNS operators what your IP is. Maybe it's the best current compromise, but it would be better to have a shared and trusted remote recursive resolver which many people talk to.

penagwin 7y ago
A Shared and trusted resolver is just centralization again though... I don’t know enough about DNS, but I’m wondering if we could somehow fit BitTorrent into the mix for the home resolver?
pdkl95 7y ago
> it reveals to eavesdroppers what DNS servers you're talking to Yes, they (probably the ISP) can do traffic analysis - which is a significant risk - but they are prevented from learning the contents fo the query which puts a limit on what they can learn. Also, the same eavesdroppers can see the TCP connection to the HTTPS server that follows he DNS request. Also, I should have mentioned that while performing recursive resolution locally does provide some actual privacy protections, it is not perfect. Name resolution as a distributed database fundamentally requires leaking some information to the servers that have the information. As long as we resolve names with anything similar to existing DNS, the best we can do is try to limit the damage to privacy. In a perfect world, we would probably use something similar to TOR to perform name resolution. Lots of inputs that onion-route queries to the actual nameservers. > it reveals to DNS operators what your IP is. Revealing my IP to ns.example.com is redundant when I'm almost certainly following the DNS request with a connection to www.example.com; the authoritative server for a domain is controlled (directly or indirectly) by the same org that controls the domain's HTTPS/etc servers.
blattimwind 7y ago
For almost every service this genuinely doesn't matter, becasue the authorative DNS server for a given domain will most likely be run by the same entity that runs the server you want to talk to. I wanna point out that a recursive resolver normally caches everything it is allowed to cache, so visting the same site a few times will not, in general, produce any extra DNS requests.

basch 7y ago

You could use k-Anonymity to request a handful of results, without the dns server knowing which result you were looking for. hash the hostname, return all results that have the same x letters as the beginning of the hash. at no point, would the actual site you are requesting leave your lan. your dns resolver would know within 1/400th (how every many results it replies with) which site you were asking for. After time, and recording patterns, they might be able to make educated guesses of which site you were requesting, but it would not be concrete evidence. https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/ https://blog.cloudflare.com/validating-leaked-passwords-with...

singron 7y ago
k-Anonymity doesn't really work with non-uniform distributions. E.g. if x is your hash prefix and d is a particular domain that matches that prefix, then we can apply Bayes rule: P(d|x) = P(x|d) * P(d) / P(x) P(x|d) is 1 in this case (the hash is deterministic), so the probability is just P(d)/P(x). E.g. if "facebook.com" doesn't have a hash collision with another similarly popular site, then you can be pretty sure that a request for hash("facebook.com") is a request for "facebook.com" for a high proportion of requests. This also adds some overhead. E.g. 400 IPs+TTLs probably wouldn't fit in a 1500 MTU packet, so it might have to be split up or k reduced to fit. From the ISP perspective, they can also tell which of the k you were interested in because you will probably send a SYN packet to that IP address. Unless you also send 400 SYN packets...

snarf21 7y ago

I understand the approaches of DoT and DoH but people keep talking about privacy and tracking but it just seems like you can just run your own un-DNS server and get the same info by looking up the IP to get the DNS. You can still be monitored and controlled by IP, right?

JohnFen 7y ago
Sorta. Not all IP addresses have a domain name associated with them. And if malicious software is actually using raw IP addresses rather than domain names, that makes it easier to stop them because you could just block those IP addresses. This is why that approach is rarely taken -- with domain names, if the IP address is blocked, you can just associate the domain name with a different one.
- ryanhallinger 7y ago
  If malware are already utilizing channels such as Youtube, the ability to block Google will be exponentially more difficult than attempt to cycle through domains.

heavyset_go 7y ago

> I'm sure Google would love to be able top bypass DNS based adblocking. Google already does this with their Chromecast line of products. Chromecasts will not adhere to your network's DNS servers, and will use Google's DNS servers. Chromecasts will fail to work at all if they cannot communicate with Google's DNS servers. If you try to redirect DNS traffic to the DNS servers of your choice, Chromecasts will not function. They won't work if you block Google's DNS servers, and you cannot change the DNS settings on the device itself.

goguy 7y ago
Source? I have a Chromecast which works fine, Google DNS servers are blocked on my network.
- throw0101a 7y ago
  Paul Vixie experienced chromecast ultra not using DHCP-supplied values: * https://mailarchive.ietf.org/arch/msg/dnsop/WCVv57IizUSjNb2RQNP84fBclI0 https://mailarchive.ietf.org/arch/msg/dnsop/WCVv57IizUSjNb2R... * https://news.ycombinator.com/item?id=19170671 https://news.ycombinator.com/item?id=19170671

tptacek 7y ago

DoH does not require centralization; rather, your linked argument redefines the term to include DNS servers that end-users run for themselves (they're "centralized" I suppose compared to a blockchain protocol?), which it obviously has to, because DoH obviously supports configurations where you run your own DoH resolvers that never speak to Cloud Flare.

ryan_hallinger 7y ago

Hi pdkl95, I would be keen to discuss the topic further with you. What's the best way to connect?