The Big DNS Privacy Debate at FOSDEM
blog.powerdns.com
blog.powerdns.com
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.
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).
Then again, Cloudflare and Quad9 terminate the connection almost instantly after finishing your request. Tested this with DoT though. (stubby with high timeout set)
Web 4.0 will consolidate these improvements, producing DNS over HTTP over QUIC over UDP.
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.
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.
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.
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.
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.
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.
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.
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).
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
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 :(
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.
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.
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.
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.
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'm in the US and feel the exact opposite. I trust Google and CloudFlare far more than AT&T or Verizon.
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.
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.
Oh well, this is the nature of evolution, like the recurrent laryngeal nerve in a giraff.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[1] Cristofaro, Lu, Tsudik: Efficient Techniques for Privacy-Preserving Sharing of Sensitive Information https://eprint.iacr.org/2011/113.pdf
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 8.8.8.8, 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.
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...
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.
> 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).
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.