Hacker News Reader

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

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

> 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."

> 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-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).

Cloudflare's entire network supports it and Firefox Nightly can consume it see: https://blog.cloudflare.com/encrypted-sni/

That means over 10% of the internet's traffic supports ESNI (even if <1% of clients consume it regularly). We're also seeing additional vendors explore ESNI, including Chrome's team who have said they will look into implementing it when the spec is finalized.

It's a draft, which means it's being pushed towards being standardized. Currently you can enable it in Firefox and Cloudflare will negotiate with eSNI. Chances are this will break some middleboxes once Chrome rolls out the standard [after the standard is finalized].

Look for network.security.esni.enabled in your Firefox config and set it true and you should be good to go.

I don’t know why you say “DoT never gained widespread adoption” - it is a very new protocol so it is way too early to assess. But it is supported in recent android and works fine.

I have not heard of any compatibility problems with DoT. Do you have any references?

I have written a DoH + DoT server https://github.com/fanf2/doh101 which I am running in production. DoT is popular, DoH is basically only used by me.

> It stops passive eavesdropping.

Do you know why Tor exists? Because things like DoH don't stop passive eavesdropping, and DoH in particular only leaks information to more parties, without stopping any eavesdropping whatsoever. I guess it's easy to confuse, thinking that DNS is some private data, but DNS is not even data, it's metadata and other sources of metadata leak much more information than DNS and let build much more detailed profile on you. For example, almost all of the top million websites are uniquely identifiable just by looking at IP addressed in IP packets, as page loads force browsers to make requests to many different IPs and give sort of fingerprints of visits. Nothing short from decentralized overlay network can help with that.

> DoT and even unencrypted DNS is blocked on a lot of free WiFi. Now what? DoH solves this issue, as it was designed to.

No, it was not designed to solve that issue. It was designed to tunnel and control DNS traffic by a corporation. Mozilla eventually agreed to provide a convenient way to block DoH as well as DoH providers agreed to be blockable. So you should expect DoH to be equally or even more blocked everywhere, where DoT is blocked.

You know there are plenty of papers on privacy. No need to repeat all that false propaganda from corporations.

Who does DoH "leak" information to besides your DNS host?

> DoH can traverse even the most locked down network over the same HTTPS channel as any other web traffic.

Given there is a virtually unlimited number of DoH servers you can trust available. With only a couple of servers available it is easy to block them.

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

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

Source? I have a Chromecast which works fine, Google DNS servers are blocked on my network.

Paul Vixie experienced chromecast ultra not using DHCP-supplied values:

* https://mailarchive.ietf.org/arch/msg/dnsop/WCVv57IizUSjNb2R...

* https://news.ycombinator.com/item?id=19170671

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.

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

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?

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.

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.

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

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.

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?

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

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.

Not really. You first have to talk to the root server, then .xxx, then the server for the domain.

The first steps of the chain are so generic there will be no useful data in there and the TTL is normally high (~a day). The last one or two steps are pretty directly connected to the service you are connecting to anyway. I don't really see an argument how caching RR is worse than centralized DNS at Google or Cloudflare or whomever, from a privacy perspective.

They do contain useful data. You are telling the root servers what tlds you are talking to and telling the tld operator what 2nd level domain you are talking to.

Yes, you hae to ask the tld's server for the NS record - the delegated domain's authoritative server. That's one request that usually has a much longer TTL. I've seen TTLs of multiple days or even weeks for NS records, compared to 5 minute TTLs (or less!) for A records.

Every few days/weeks the tld gets a single query that tells them you were making some sort of request so an unknown domain anywhere in queried delegation. That query only includes the 2nd level domain and a request for that domain's nameserver(s). The rest of the recursive resolution and most future queries only need to involve the domain's nameserver.

Yes, some information is leaked. This is unfortunate, but there is a huge difference between leaking that you occasionally visit something at exsmple.com and leaking your pattern of life (the exact subdomains you visit with ~minute-ish granularity).