Hacker News new | past | comments | ask | show | jobs | submit login
The Big DNS Privacy Debate at FOSDEM (powerdns.com)
107 points by detaro 40 days ago | hide | past | web | favorite | 62 comments

DNSCrypt has been around for a decade and works really well. Did everyone forget about it?

It's objectively better than running DNS queries over HTTPS: still UDP based, no need to trust a CA but only the DNS server public key, can be cached locally or network-wise, perfect forward secrecy.

There are clients[1] for Windows, Android, BSD, Linux, macOS and lots of providers[2]. It's really a shame it hasn't been made into a standard.

[1]: https://github.com/jedisct1/dnscrypt-proxy

[2]: https://dnscrypt.info/public-servers

Some would argue "still UDP based" is objectively worse, since it can be blocked.

I don't think DNSCrypt is better for caching, doesn't it just protect one "leg" from a client (which can be a local cache) to a resolver (which also can be a cache) just like DoH? Similarly for pinning keys (although I think DNSCrypt made exchanging keys easier).

blocking or not blocking DNS is a two edged sword.

as we see in the discussion about the chromecast ultra: https://news.ycombinator.com/item?id=19170671 it is not necessarily desirable to have a way for apps to resolve DNS that can't be blocked at all.

In the internet of the future, DNS will move from UDP to TCP because it's better, and HTTP/3 will move from TCP to UDP because it's better.

Web 4.0 will consolidate these improvements, producing DNS over HTTP over QUIC over UDP.

Probably, yes. The key from that perspective is to have it in the same format as the content traffic.

We already have DNS over HTTP(S) now.

What a mess.

Major advantage is the latency. TCP needs 3 trips, TLS an additional 4. With dnscrypt you have one request and one response.

Then again, Cloudflare and Quad9 terminate the connection almost instantly after finishing your request. Tested this with DoT though. (stubby with high timeout set)

Are you sure that's not a problem with the client? It seems Cloudflare supports leaving the connection open just fine (at least using the cloudflared client).

>works really well

Yes it works, but the setup can get messy. It used to break Ubuntu for me (like beyond repair and needed a full reinstall).

I agree, I wish there was more consensus about how to lock down DNS traffic. It's surprising to me that it's taken this long to start getting mainstream recognition. DNSCrypt is probably best positioned to become a standard if anything. I'm going to give the latest version a try (the one that broke for me was a couple of years ago) hopefully it's better than before.

That's interesting. How did it break your system?

I've been using it on OS X / macOS for years. Occasionally I'd run into an ISP that blocked it or a resolver that was slow or down but the software was always solid.

It messed up the network-manager/DNS iirc, though this was a while ago as I mentioned. The problem had something to do with the configuration of the Ubuntu package which was kinda fucked up so that didn't help matters, this is pre-16.04 so I'm hoping it got sorted out later on.

The discussion is not so much about which encryption technology to use, but on whether browsers should silently redirect DNS traffic to big US companies.

On a related note, I recently found out that Chrome uses its own DNS resolver, ostensibly to improve performance. On some Android devices, this ignores the nameserver precedence set against network connections on the device. The result is that it will often send DNS queries to the nameserver attached to the physical network adapter and not the one attached to the VPN interface. It breaks queries for intranet servers and it breaks loopback-VPN-based ad blockers (a common workaround to manage your own hosts file on Android without rooting your device and breaking many root-hostile apps). There's a flag (async dns) in Android Chrome to disable the internal resolver and use the system resolver instead, but this flag is no longer present on desktop (where a startup parameter must be used).

My point is that, as alluded to in the article, changing how DNS works can have serious side effects. The fact that, as unintentional as it may have been, one of the world's biggest ad networks broke ad-blocking on a number of devices by changing how they handle DNS queries is worrying. I'm concerned that as DoH (or DoC as the article refers to it) proliferates, it'll be used less to circumvent censorship and more to take away control from end users and enterprise network administrators. Every app, the browser included, could creep towards using their own internal DNS query handler, using nameservers they trust to delivery their analytics and advertising queries.

Additionally, giving DoH/DoC choice through the browser suggests that the browser might return different results from other software on the device. This sounds disastrous.

And I suspect that the oppressive regimes that always come up in discussions about DoH would simply block the IPs of those cloud resolvers, which seem to rely on having a well-known IP or domain name.

In India, several websites get blocked by different ISPs based on some highly unsubstantiated petitions to some court that doesn’t understand what the right move is and just sends the list of domains to be blocked to some ISPs, who gladly comply without any checks or questions. Users see a message saying that the site has been blocked because of some order from the Department of Telecommunications.

There is no grievance management process, no way for legitimate sites to get a quick reprieve when they get blocked either due to operator error or issues with the petitions not being vetted and investigated for malicious intent (a competitor could easily knock you off in some states or regions and you wouldn’t even know).

While there are activists working on policies and campaigning for better laws, we really need stronger technological solutions against these (usually ridiculous) blocks that insult “due process” and harm people.

India is also very quick to rap on large multinational companies whenever they seem to provide something that those in power (or their supporters) frown upon. So centralized providers like Google DNS or Cloudflare DNS would have some tough times with the governments, since both have physical presence in the country with their servers/data centers.

A decentralized and yet secure/private DNS may be more resilient than these DoC (DNS over Cloud) providers if we have to deal with government censorship effectively.

One of the options I've thought of (and I'm sure many others have as well) is to have all zones distributed in a P2P manner via ICANN. To not put too much burden on ICANN and keep things decentralized, have ICANN at the root of the DNS PKI and have all zones signed by the responsible party.

This would solve a few of the big problems we have:

* All sorts of MITM and evil resolver attacks would be prevented.

* Since DNS queries are local, there would no longer be a privacy concern with resolving a name.

* Even if the P2P network mechanism were to be blocked, since every host connected keeps a full record (though not necessarily with history) it can still be distributed via sneakernet.

* DNS updates are as fast as the network is, no longer depending on turtles caching all the way down.

* DNS amplification? That's gone, as resolvers no longer need to query external sources.

As many will quickly notice, we would likely still need remote resolvers for battery constrained devices as this would keep the network interfaces busy.

The one big political issue that would put a stop to this is that this would cause all zones to be world readable. Many people treat zones as something private and to them exposing the zone file is the same as exposing their network. My view is that if it has a publically routable IP then it is already exposed, but not everyone shares my view.

I've also thought of this. With the plentiful availability of storage and bandwidth we have today, there is little technical reason why public resolvers and privacy minded individuals couldn't download and cache zone files in bulk.

As you say though, I suspect the inertia behind the status quo is so strong that there is little chance of such a radical change being accepted.

> The one big political issue that would put a stop to this is that this would cause all zones to be world readable. Many people treat zones as something private and to them exposing the zone file is the same as exposing their network. My view is that if it has a publically routable IP then it is already exposed, but not everyone shares my view.

I really don’t get this view either. There may be more cases supporting zone files being world readable than not (I can’t think of any cases for the latter except for censorship and control).

The concerns just don't stop with blocking access but privacy as well: Some ISPs, I'd wager, are intercepting all unencrypted traffic too https://news.ycombinator.com/item?id=12091900. As long as one types in https instead of http, DNS and content based censorship should stop working, at least in theory, if one can use custom DNS providers over TLS, Https, or DNSCrpyt.

On Android, consider installing intra https://getintra.org to use a DNS over Https server of your choice, and switch to using Firefox instead of Chrome (someone pointed out in comments here that Chrome uses its own DNS resolver).

An example of how to set up AdGuard DNS (privacy oriented) on Android 4 and later: https://news.ycombinator.com/item?id=18791895

On Windows, consider using SimpleDNSCrpyt https://simplednscrypt.org/


Generally you could try and setup pie-hole, as well: https://news.ycombinator.com/item?id=18075159

Anecdotal: DNS based censorship and blocking used to be a thing back in the day in India, but things have moved on to other methods (sni based I think).

This probably may be true for some ISPs, but is not true everywhere. I still see sites blocked when visiting the http version, while they go through fine when visiting the https version. That means they’re not doing SNI inspection, right?

I'm disappointed that the fact it will break things only got a mention, and yet the browsers are pushing for using DoH via cloud providers.

My NAS isn't externally resolvable; after all, it's not externally reachable either. And now I have to refer to it by IP address because the Chromecast insists on using Google's DNS servers.

People seem to be unwilling to address known issues before switching defaults :(

I attended the DoH talk by Daniel Stenberg at FOSDEM. When talking about alternatives he didn't mention Dan Bernstein's DNScurve ( https://dnscurve.org/ ).

It has low adoption and is not on a standards track (as far as I know) but I think it's the best proposal for DNS privacy and security so far.

DJB has a long history of producing outstanding software that almost nobody uses because of weird licensing, poor documentation or his prickly personality. He would do really well to get a PR agent or something, because technical excellence is rarely enough to succeed in a market.

DNSCurve is over; DoTLS and DoH provide essentially the same value in essentially the same deployment mode, but with mainstream support.

DoH failed to keep the important part of DNS, which was statelessness.

Running a stock or DNSCrypt resolver for 10k QPS requires a small to medium sized box that is within the technical realm of most people to operate. Adding stateful connection tracking now creates an operational burden that most IT folks would say "screw it, send it to the cloud."

This centralizes the DNS in to the hands of a half dozen organizations that can operate at that scale, and they also happen to be the ones driving the policy forward.

I don't honestly know whether, if I had the choice, I'd take DoHT or DNSCurve. But that's not really my point. No matter how much I might like DNSCurve, it's not going to happen at this point: DoH will be the mainstream secure resolver going forward, because it's firewall-friendly and will have mainstream browser support. With DoH widely deployed, the argument for DNSCurve is cut back drastically.

It's a very positive thing, to my mind; it's equally fatal, I think, to the arguments (such as they were) for DNSSEC --- which not only centralized DNS but also TLS security, and handed them to world governments.

I also think:

1. No matter what the protocol, centralization of "off-net" DNS services inevitable, for reasons having little to do with performance.

2. People with concerns about Google and Cloud Flare (it me!) can easily run their own off-net resolvers, and people will inevitably start privacy-preserving DoH resolvers that are open to the public.

3. Over time, the performance implications of TLS for DNS lookups will become less and less a factor.

As they say, if it's free, then you're the product. I (as a European) have much more confidence in my ISP to guarantee my privacy than in a company which mostly makes money out of advertisement.

Your ISP doesn't sell user data?

I'm in the US and feel the exact opposite. I trust Google and CloudFlare far more than AT&T or Verizon.

With these proposals you still have to trust your ISP in addition to trusting Google and Cloudflare. You can avoid trusting all three, your ISP, Google, Cloudflare by trusting instead a single VPN provider of your choice (or a hosting provider where you can run your own VPN server).

A VPN provider has a much better source of data to mine than just about anyone else. On top of that, figuring out which ones deserve to be trusted is near impossible.

It doesn't have more data to mine than your ISP. It's not harder to figure out who to trust than with any other company. But unlike with any other company there is so much competition across the globe, that you can strategically pick specific jurisdictions and providers known to fight for your interests.

> It doesn't have more data to mine than your ISP.

Let's say you are behind a NAT and then you sign on to your VPN. You've helpfully disambiguated yourself from everyone else behind the NAT. Let's say you head out to a coffee shop and sign in to you VPN. Your ISP can't monitor you, but your VPN provider could.

> It's not harder to figure out who to trust than with any other company.

Have you ever looked for VPN reviews? There are many sites that seem to do nothing except review VPNs. One example: https://www.trusted-vpn.com/. And its "reviews" are basically all advertising copy. So, maybe you check out a bigger name site: https://www.pcmag.com/article2/0,2817,2403388,00.asp. And ... it's more advertising copy. The third sentence in the article: "Everyone ought to be using a virtual private network, or VPN, as often as possible" - which again, sounds more like an article trying to push VPN sales (with helpful affiliate links!) than to provide actual reviews.

And the thing is, let's say you do find some site that is both trustworthy and doesn't seem to be trying to push you to click an affiliate link. What can a reviewer actually tell you about how you should trust the VPN company? Basically all they can do is read the privacy policy and rate that - which is absolutely no better than believing Google or Cloudflare when they say they won't track you with their DNS servers.

So, by all means use a VPN - but don't trust it.

Read the article.

One nice aspect of DoH is that you can use it to circumvent local, lame DNS censorship. But ideally you will use a DoH server that is not run by for-profit companies known for data mongering.

Local censorship is still in your jurisdiction; if you have a grievance with it, you can address that (unless it is blocked for a generally accepted reason).

With DNS in cloud, you don't have that option. If the cloud companies do not respond to you, what are you going to do? The Google lack-of-support is well known for how it operates.

If the cloud companies do not respond to you, what are you going to do?

Use another, without having to cancel my whole Internet service, just by changing a configuration.

That said, I think the ISP should probably be the default.

I’ll actually use this as an example how that saying is wrong.

ISPs may be better in some regards because they are smaller. Some of them may also just not be competent enough to seriously harm you.

But not for a second do I believe they care about my privacy.

That tired saying is also full of holes: paying doesn’t stop you from being the product as well as the customer if the company can pull it off. That’s why they show you ads in cinemas even if you paid for the ticket. Conversely, not paying really does not change the incentives for Google and others to retain you: if everyone switches to some other search and email, they are done for no matter what.

I'm disappointed by this situation where we have to shove encryption in at the application layer one application at a time because we couldn't get our act together with ipsec. I understand how it's come to be, but from an engineering perspective, it's absurd to move dns into https.

Oh well, this is the nature of evolution, like the recurrent laryngeal nerve in a giraff.

I am not sure you need to do it at the application layer. All you need is a local caching resolver that your apps query over local host using standard methods. Then the local service can do all the fancy you want.

Today, I have this setup for work. I don't like them spying on me while at work. So I have setup a local resolver that forwards some request to the companies resolver, and others over a secure line to a set of public resolver. I did not need to change any software.

My use of "application" is ambiguous. I was referring to the fact that DoH moves DNS from on top of udp/tcp to on top of https, itself on top of tcp, primarily to benefit from the 's' in https.

I actually also run a DoH proxy on my home router and point dnsmasq (also on the router) at it, so all my home network DNS goes out over https.

Through the two major DNS privacy talks on FOSDEM I felt a bit at odd that so much effort is being put into the idea that giving all information to google will give best privacy. In basic security theory we talk about assets that need to be defended, and attackers we need to defend against. Why give everything to a company which revenue is based on breaking privacy? It sound completely incompatible with the idea of privacy.

Running your own resolver will give the authoritative servers the ip address of the request, but does this leak any assets to any potential attacker? The owner behind the authoritative servers already get the web logs so what additional information is being leaked. It seems to me that in order to get higher level of privacy you would need to run a VPN or Tor, in which case the DNS traffic can just go through the same path.

It's worse than that: you already have to trust your ISP, but with third party DNS resolver you not only have to trust your ISP, but also another third party. Encrypted SNI is another sneaky proposal that claims it can help with that, but cannot actually. Even in the ideal case when everyone is using ESNI, there is still a lot of information that you have to trust your ISP with, like access patterns, IP addresses, response sizes, etc. and on top of that trust an extra third party with DNS.

Basically it's all awful and ill-advised form security and privacy perspective, you always need at least a VPN if you can't trust your ISP. DoH can only make it worse.

>Running your own resolver will give the authoritative servers the ip address of the request, but does this leak any assets to any potential attacker? The owner behind the authoritative servers already get the web logs so what additional information is being leaked.

This is addressed in the panel. The argument is that there is some "privacy mixing" because owner of the authoritative server only sees a highly-trafficked resolver as the source, and not your home network resolver.

Yes, the authoritative server get less data from the DNS server but the owner of the domain already get the information from web server logs and similar sources. I do not see how dns mixing provide any privacy in any common threat model.

In the first case a client that request a webpage contact company X authoritative server with private information [IP ADDRESS], creating a record on the DNS server, and then visit company X web server creating a second record at the same company with the same [IP ADDRESS].

In the second case a client request a webpage of company X by contacting google, creating a record on google DNS server with [IP ADDRESS], and then visits company X and create a record there with [IP ADDRESS].

In one case one company has the data, and in the second case two companies has the data. It does not make any sense.

Potential workarounds:

1. Round Robin your DoH requests across several providers. Eg, if CloudFlare sees one quarter of your DNS requests it's less revealing then if they see all of them.

2. DNS proxies. Sort of like a VPN for the DNS requests such that they're aggregated to one source IP before being passed to the DoH provider. Done at the ISP level? Or some other arrangement. The VPN here would not be privy to the requests due to TLS.

These ideas may require more work to be practical.

Round robin won't work because a 25% sample is just as useful as a full feed. All they need is enough users to provide a statistically significant representation of traffic.

For you personally, if you send a query for www.example.com to one provider, and a query for images.example.net to another, you've outed yourself as browsing example.com to both.

Agreed, see reply to your sibling comment for a less-broken idea

1) seems unlikely; a 25% sample is probably quite representative.

2) that's essentially what a typical DNS provider like Cloudflare or Google DNS is: they proxy your requests back to the authoritative DNS servers, then return the response to you.

1) Fair enough, 25% of the requests would just take ~4x as long to get a more-or-less complete sampling. So how about a revised version: shard the requests, so CloudFlare only sees A-G, Google only sees H-P, etc.

2) No argument about that. I'm considering the privacy angle. A pre-DoC proxy would know your IP but not the DNS request contents, and the DoC provider would have the request but not the original IP.

Oh, I didn't understand (2), you mean a simple TCP proxy. Well, I guess one could already use Tor for that.

There is a lot of misinformation and false choices. The ISP scaremongering seen here is not real and only serves to further entrench SV based global surveillance data collection unimpeded.

An ISP is local, accountable to its customers and more important subject to local laws that can be enforced. An added benefit is ISPs cannot collect, collate and correlate vast amounts of global user data. This is a huge win for wider society.

Compare that to unaccountable global organizations built on stalking and hoovering up every single piece of user data with zero regulation and subject to and support of their own home governments.

With this already in play 'concern' with localized ISPs cannot be justified without first offering more immediacy and potent solutions to the larger global surveillance problem.

Here's the thing, right. SV global surveillance gets us better ads.

Meanwhile, governments ("An ISP is local" - you've GOT to be joking) actually systematically damage people based on surveillance data. Try visiting Pakistan and then see how governments react to that country's stamp being in your passport.

But it's hardly just that. Credit reports (are government mandated, and a monopoly, they are therefore government) really damage people. Police actions, "random" searches, ...

And of course, heavy handed copyright enforcement.

So we would be transfering DNS authority from entities, the SV companies, that have a VERY long history of not abusing that data, to entities, the governments that not only have a long history of abusing this data, but haven't even stopped doing so when caught with their hands in some cases literally torturing people.

Governments' accountability is a JOKE, a sad, distasteful joke. I will not be counting on that, sorry. And there is nothing local about those local ISPs in any of the countries I use them.

So: no thanks, given those choices, I'll take the Google/Cloudflare option, thank you very much.

Is the research of homomorphic encryption far enough that it's practical to implement for DNS? The server would accept DNS queries using such cryptographic algorithms on encrypted database, that he nor anybody else can't say which record was queried. Only the client.

I think the science is there and the technology exists as a proof of concept [1]. The hard part, as is often the case, is getting the providers to adopt it and users to use it.

[1] Cristofaro, Lu, Tsudik: Efficient Techniques for Privacy-Preserving Sharing of Sensitive Information https://eprint.iacr.org/2011/113.pdf


Encryption usually solves three problems:

1. Authenticity of data; i.e. fixing DNS spoofing.

2. Privacy

3. Censorship

Problem 1 is fixed today by DNSSEC.

The best solution for problem 1, 2 and 3 would be if IPsec had a working and deployed PKI, so IPsec could be used for all IP-based traffic, and nobody had to worry about encryption on any layer above that.

Lacking that, the next best thing for problem 2 would be for DNS to use TLS and/or DTLS, and there is a standard for DNS over TLS (DoT), which makes perfect sense to use today between resolvers and authoritative servers, and between master servers and slave servers. However, this does not solve problem 3, since DoT uses a separate port and can be trivially downgraded by a MITM to use old non-TLS DNS. In theory, this could be fixed by something similar to how DANE solves the same problem for SMTP, in that a separate channel can be used to indicate not to allow protocol downgrades.

But, this problem of censorship is in practice, today, primarily an issue between the client and the resolver. If that traffic can use DNS-over-HTTPS, this would avoid problem 3 as well.

Note that none of this requires any centralization of resolvers, and is technically completely tangential. The problem of centralized resolvers existed since centralized resolvers first appeared; witness the prevalence of using Google’s, etc. This is a huge problem independent of DNS-over-HTTPS.

The connection, as far as I can tell, between DoH and centralization is that browsers want to fix as many as possible of problems 1-3, and using a centralized provider of DNS-over-HTTPS does that, at the expense of centralization and a single point of failure for problem 1-3. This is of course a terrible idea. But I can certainly see why browser vendors are attracted to the idea, bad though it may be.

DoC doesn't actually address 2 or 3.

I trust Sonic to not data mine or game my DNS queries much more than I trust Google or Cloudflare. I actually run my own recursive resolver locally, but if Firefox or Chrome default to DoC then the effect will be to lessen the privacy of Sonic Internet users, and users of similarly trustworthy ISPs. Worse, the techniques employed by browsers to select between a DoC resolver and a local resolver will inevitably on occasion break anonymizing VPN setups. When the browser becomes the OS, you lose interoperability with third-party software as browsers aren't built as platforms for local interfacing.

And centralization makes censorship easier. A U.S. court may not be able to block resolution of a domain under co.uk, but it definitely can force Google or Cloudflare to block it. And it's much easier to execute an injunction against a small handful of service providers that reach 90% of users than trying to execute one to hundreds or thousands of smaller providers. Here's a recent injunction ordering Cloudflare to block a DNS name: https://torrentfreak.com/us-court-lists-dns-and-routing-serv...

> DoC

Surely you mean DoH?

> I actually run my own recursive resolver locally

As do I.

> I trust Sonic to not data mine or game my DNS queries much more than I trust Google or Cloudflare. […] And centralization makes censorship easier.

Oh, I agree. When you can't trust the single point of failure to not actually fail or not to be already fundamentally failed, then everything about centralization is bad.

> > DoC

> Surely you mean DoH?

DNS over Cloud (DoC) is the term coined in the article to differentiate the underlying transport (DoT, DoH) from it's deployment (centralization).

Yeah, centralization against censorship is oxymoron.

DNSSEC doesn't really fix any of authentication today, for a number of reasons:

1. Almost no major domains are signed or have plans to sign (despite DNSSEC being one of the oldest "security" standard efforts at the IETF): https://twitter.com/tqbf/status/1086061495811743747

2. Browsers have removed support for DNSSEC, and are not adding it back.

3. DNSSEC solves only the server-to-server authentication problem, but not the (much more common) client-server authentication problem that DoH solves.

4. And, of course, the authentication solution DNSSEC offers is effectively key-escrowed to world governments.

There are other reasons as well, but that's a condensed version of the argument for why DoH is a live effort with gathering mainstream support, and DNSSEC is not.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact