Privacy Primer —

How to keep your ISP’s nose out of your browser history with encrypted DNS

Using Cloudflare’s 1.1.1.1, other DNS services still require some command-line know-how.

Encrypting DNS traffic between your device and a "privacy-focused" provider can keep someone from spying on where your browser is pointed or using DNS attacks to send you somewhere else.
Encrypting DNS traffic between your device and a "privacy-focused" provider can keep someone from spying on where your browser is pointed or using DNS attacks to send you somewhere else.

The death of network neutrality and the loosening of regulations on how Internet providers handle customers' network traffic have raised many concerns over privacy. Internet providers (and others watching traffic as it passes over the Internet) have long had a tool that allows them to monitor individuals' Internet habits with ease: their Domain Name System (DNS) servers. And if they haven't been cashing in on that data already (or using it to change how you see the Internet), they likely soon will.

DNS services are the phone books of the Internet, providing the actual Internet Protocol (IP) network address associated with websites' and other Internet services' host and domain names. They turn arstechnica.com into 50.31.169.131, for example. Your Internet provider offers up DNS as part of your service, but your provider could also log your DNS traffic—in essence, recording your entire browsing history.

"Open" DNS services provide a way of bypassing ISPs' services for reasons of privacy and security—and in some places, evading content filtering, surveillance, and censorship. And on April 1 (not a joke), Cloudflare launched its own new, free high-performance authoritative DNS service designed to enhance users' privacy on the Internet. This new offering also promised a way to hide DNS traffic completely from view—encryption.

Named for its Internet Protocol address, 1.1.1.1 is the result of a partnership with the research group of APNIC, the Asia-Pacific Internet registry. While it's also available as an "open" conventional DNS resolver (and a very fast one at that), Cloudflare is supporting two encrypted DNS protocols.

While executed with some unique Cloudflare flare, 1.1.1.1 isn't the first encrypted DNS service by any means—Quad9, Cisco's OpenDNS, Google's 8.8.8.8 service, and a host of smaller providers support various schemes to encrypt DNS requests entirely. But encryption doesn't necessarily mean that your traffic is invisible; some encrypted DNS services log your requests for various purposes.

Cloudflare has promised not to log individuals' DNS traffic and has hired an outside firm to audit that promise. APNIC wants to use traffic data to point to the IP address, which has the unfortunate legacy of being a dumping ground for "garbage" Internet traffic, for research purposes, according to APNIC's Geoff Huston. But APNIC won't have access to the encrypted DNS traffic in this case, either.

For users, taking advantage of encrypted DNS services from Cloudflare or any other privacy-focused DNS services is not as easy as changing a number in network settings. No operating system currently directly supports any of the encrypted DNS services without the addition of some less-than-consumer-friendly software. And not all of the services are created equal in terms of software support and performance.

But with consumer data as product all over the news as of late, I set out to see just how to get Cloudflare's encrypted DNS service working. And overcome by my inner lab-rat, I ended up testing and dissecting clients for multiple DNS providers using three of the established protocols for DNS encryption: DNSCrypt, DNS over TLS, and DNS over HTTPS. All of them can work, but let me warn you: while it's getting easier, choosing the encrypted DNS route is not something you'd necessarily be able to walk Mom or Dad through over the phone today. (Unless, of course, your parents happen to be seasoned Linux command-line users.)

How DNS works.
How DNS works.
Sean Gallagher

Why are we doing this, again?

There are plenty of reasons to want to make DNS traffic more secure. While Web traffic and other communications may be protected by cryptographic protocols such as Transport Layer Security (TLS), almost all DNS traffic is transmitted unencrypted. That means that your ISP (or anyone else between you and the rest of the Internet) can log the sites you visit even when you use another DNS service and use that data for a number of purposes, including filtering access to content and collecting data for advertising purposes.

What a typical DNS conversation between a device and a DNS resolver looks like.
What a typical DNS conversation between a device and a DNS resolver looks like.

"We have a 'last mile' problem in DNS," said Cricket Liu, Chief DNS Architect at the network security company Infoblox. "Most of the security mechanisms we have dealt with server-to-server issues. But we have this problem where we have stub resolvers on various operating systems and don't really have any way to secure them." That's particularly a problem, Liu said, in countries that have a more hostile relationship with the Internet.

Just using a non-logging DNS service helps to some degree. But it doesn't prevent someone from filtering those requests based on content or capturing the addresses within them with packet capture or deep packet-inspection gear. And in addition to simple, passive eavesdropping attacks, there's also the threat of more active attacks against your DNS traffic—efforts by an ISP or a government on the wire to "spoof" the identity of a DNS server, routing traffic to their own server to log or block traffic. Something similar (albeit apparently not maliciously) appears to be happening with AT&T's (accidental) misrouting of traffic to Cloudflare's 1.1.1.1 address, based on the observations of forum posters on DSLReports.

The most obvious way to dodge monitoring is by using a virtual private network. But while VPNs conceal the contents of your Internet traffic, connecting to a VPN might require a DNS request first. And once you've launched a VPN session, DNS requests may occasionally get routed outside of your VPN connection by Web browsers or other software, creating "DNS leaks" that expose which sites you're visiting.

That's where encrypted DNS protocols come in—the DNSCrypt protocol (supported by Cisco OpenDNS, among others), DNS resolution over TLS (supported by Cloudflare, Google, Quad9, and OpenDNS), and DNS resolution over HTTPS (currently supported by Cloudflare, Google, and the adult-content-blocking service CleanBrowsing). Encrypted traffic both ensures that traffic can't be sniffed or modified and that requests can't be read by someone masquerading as the DNS service—eliminating middle-man attacks and spying. Using a DNS proxy for one of these services (either directly on your device or on a "server" inside your local network) will help prevent VPN DNS leaks, since the proxy will always be the fastest-responding DNS server.

That privacy does not come packaged for mass consumption, however. None of these protocols is currently supported natively by any DNS resolver pre-packaged with an operating system. All of them require the installation (and probably compilation) of a client application that acts as a local DNS "server," relaying requests made by browsers and other applications upstream to the secure DNS provider of your choice. And while two out of three of the technologies are proposed standards, no option we tested is necessarily in its final form.

So if you choose to dive into encrypted DNS, you will probably want to use a Raspberry Pi or some other dedicated piece of hardware to run it as a DNS server for your home network. That's because you'll find that configuring one of these clients is more than enough hackery. Why repeat the process multiple times when you can just query your local network's dynamic host configuration protocol (DHCP) settings to point everything at one successful installation as a DNS server? I asked myself this question repeatedly as I watched clients crash on Windows and fall asleep on MacOS during testing.

Channel Ars Technica