Cloudflare and Quad9 Aim to Improve DNS

Nearly every task on the Internet, from browsing to email to gaming to voice calls, involves domain-name lookups you never see happen and that are almost always insecure. Even when your activities are encrypted — whether you’re browsing https-protected Web sites or using a VPN — these domain name lookups can leak information. That can mean your Internet service provider, anyone with whom you share a Wi-Fi router (like in a coffee shop), data centers, governments, and others along the way might be able to glean insight into your behavior, including what you’re reading and with whom you’re interacting.

Proposals to improve security and reduce your exposure haven’t achieved much traction despite enormous effort expended. But two new public DNS services that you can use instead of the one provided by your ISP could make a big difference. These services expand on what existing public DNS services have offered, especially the well-known Google Public DNS.

Cloudflare and Quad9 offer public DNS servers that provide a combination of verification, privacy-focused protocols, and encryption to mitigate DNS’s information leaks.

I’ll cut to the chase to tell you how to configure your devices to use these services before getting into the nitty-gritty of how DNS works and how these services improve on an insecure and easy-to-corrupt design.

Configure Your Device to Use Cloudflare or Quad9

On your Mac, you can set DNS servers for specific network adapters (Ethernet, Wi-Fi) that stick no matter what network you connect to.

1. Open System Preferences > Network > Advanced > DNS
2. Click the + button under the DNS Servers box. Enter the IP address of the first DNS server.
3. Repeat step 2 for a second server, if available, in case the first isn’t available or is very slow to respond. (You can drag server entries to change the order.)
4. Click OK, and then click Apply.

For the different services, the IP addresses to enter are:

• Cloudflare: 1.1.1.1 and 1.0.0.1 (see note below)
• Google Public DNS: 8.8.8.8 and 8.8.4.4
• Quad9: 9.9.9.9 and 149.112.112.112

There’s no harm in entering DNS servers for multiple services and rearranging them to see which you prefer.

Note that some operating systems, network hardware, and software treat Cloudflare’s 1.1.1.1 address as a catchall, garbage, or internal address. As a result, you might not be able to visit Cloudflare’s Web site at that address or use the DNS server there — I have this problem on my CenturyLink fiber connection in Seattle. You should be able to use the backup 1.0.0.1 address to reach the Web page and for DNS and omit the 1.1.1.1 address in the DNS setup.

Also note that Quad9’s address above includes a DNS blocklist, so that your devices won’t connect to millions of malicious addresses the organization has identified. You can use an alternate set of DNS servers that bypass that blocklist: 9.9.9.10 and 149.112.112.10.

In iOS, DNS server settings tend not to work the way most people want, which is as in macOS: setting the details once and having them work on every network to which you connect. The settings are required for each network. Worse, we’ve found in our testing that after changing DNS values, the settings revert to Automatic and the server IP addresses we entered are tossed. There’s also no way to set DNS servers for cellular connections.

On your own networks, I recommend changing the DNS server settings on your router. The details vary widely by manufacturer, but look for a DHCP or Network settings area in which you can specify both a range of addresses assigned on a local network and the DNS servers that are passed along with the address assignment.

For other operating systems, consult the services’ guides: Cloudflare, Google Public DNS, and Quad9.

If you’re curious about how DNS works, and the kinds of problems that Cloudflare and Quad9 promise to address, read on.

Recursive and Decentralized, DNS Predates Internet Risks

The domain name system dates back to the earliest days of the Internet, and it often shows. DNS has gained a lot of functions over the years, but at its core, it’s a directory that matches human-readable domain names (like www.tidbits.com) with their underlying IP addresses (64.62.135.130) necessary to make connections.

Nearly every Internet connection — like visiting a Web page — involves silently passing a DNS lookup to a DNS server that’s specified in your device’s network configuration. In many cases, your software looks up multiple domains for a single action, such as for a Web page that has images and style sheets hosted on different servers.

The lookup then bounces from DNS server to DNS server in a decentralized, distributed hierarchy to find the DNS server that’s the authoritative endpoint for that domain. Finally, that DNS server sends back a response with the answer required or an error that there’s no answer for that lookup.

Every Internet-savvy device and operating system has what’s called a “stub resolver” that knows just enough to pass your queries on to a DNS server, also called a “resolver.” That DNS server is generally run by your ISP. Or it might be a generally accessible one, like Google Public DNS. (You could even run one yourself, if you’re a masochist.)

How does this work? In a Web browser query for www.tidbits.com, for instance, your Mac or iPhone’s stub resolver passes that full query — called a “fully qualified domain name” — to your DNS server, which breaks it up into pieces. It starts with the end, which has an implicit “.” as in “www.tidbits.com.”, even though you rarely see that final dot. That dot indicates the root level of DNS, which is handled by a number of servers around the world that have authoritative information for all the top-level domains, like .com, .uk, and .aero. Your DNS server knows how to reach all the root servers, and, in this example, asks one of them for a .com server. Once it has been passed to a server that handles .com, your request for details about tidbits.com then goes to TidBITS’s DNS host, which runs nameservers that provide a response for www.tidbits.com in particular. Finally, the 64.62.135.130 IP address is then sent back your DNS server and on to the stub resolver.

DNS is distributed, in that there’s no authoritative list for every fully qualified domain name in the world. The root servers know only about the top-level domains; the top-level domain servers only know about the domains within their purview; and so on down the hierarchy. DNS is also decentralized, in that there’s no single point of authority, but, rather, responsibility for lower-level domains is delegated down a branching tree.

That explained, let’s look at what problems need to be solved.

DNS Weaknesses from Right to Left

Like DNS, the early Web was completely insecure, but the builders of those early servers and browsers, like Netscape, quickly discovered that e-commerce, banking, and other commercial uses required a secure path. Thus was SSL born, to provide negotiated encryption between the two points. It took almost two decades for Web encryption, with SSL now supplanted by TLS, to become standard even on sites that carry no financial or other confidential information.

DNS remains enormously behind the Web, even though many different and often competing efforts to make it better have been floated. Some have even been officially approved — just not fully deployed. In short, DNS leaks like a sieve and has many potential points of interception.

Most DNS lookups are sent in the clear, so even if everything else you do is secured with encryption, the domains you’re visiting, sending email to, uploading files to, and so on all pass over your local network and all intermediate networks. Anyone sniffing traffic anywhere along the line can see where your traffic is going, if not its contents.

If you use a VPN connection, your DNS lookups should pass through the VPN and not be revealed locally, but some information can still leak out. Sites like DNS Leak Test can help you check to see if your VPN is leaking and offer advice on how to fix problems.

Even if nobody is sniffing your local network or points in between, DNS servers always send the entire query to each point on the chain of resolution. So everything from the root on down to the individual domain DNS host knows the entire domain name you want. That makes the DNS servers themselves potential sources of information about your activities.

Also, DNS responses could once easily be “poisoned,” allowing correct results to be replaced with ones that attackers want to use. There was no effective way for a DNS server or stub resolver to identify whether or not a response came from the actual definitive source. One form of poisoning led to one of the Internet’s worst security flaws, which was patched by every operating system maker and DNS server developer before it became widely known in 2008.

While that vulnerability has been patched, it remains possible for someone to access a public Wi-Fi network and use a variety of simple techniques and readily available software to provide fake responses to DNS lookups. The encryption used for https connections largely prevents this from being effective: for instance, your browser would throw an error about a certificate being invalid and warn you that someone was trying to intercept your connection. But it remains possible.

All this could change if only all the institutions in the world providing DNS service would improve their systems, educate users, and agree on new initiatives that haven’t yet been fully adopted. If that sounds unlikely, you’re not wrong.

In the meantime, you can improve performance and likely increase privacy by switching to a new DNS server. The new public DNS services from Cloudflare and Quad9 address some of these problems. If you’ve been using Google Public DNS, you’ve received some, but not all of these benefits.

Plugging DNS Privacy and Integrity Leaks

Cloudflare and Quad9 both offer free public DNS with a variety of techniques and capabilities, some of which are not yet widely supported. I’ll start with what they provide before discussing the two organizations and issues of privacy and data collection. Google Public DNS also offers some of these features.

This will get a little technical, but it’s worth reading to understand where the points of weakness lie. Here are the main features of the different DNS services:

• Validity: Using cryptographic signatures, DNS servers can now determine that answers are valid along the entire hierarchy of DNS servers. This technology, known as DNSSEC, blocks attempts to provide fake answers and poison DNS. While some DNS servers from ISPs support this too, it’s specifically offered by Cloudflare, Google Public DNS, and Quad9.
• Reducing information leakage: Instead of sending the fully qualified domain name to the root and every server in between, a protocol called “query name minimization” breaks up the domain into its constituent parts. The DNS server then sends the minimum necessary information to each point on the chain. This prevents intermediate servers from gathering information about your queries and foils sniffers who gain access to the networks over which the queries pass. Cloudflare and Quad9 support query name minimization, but Google Public DNS doesn’t.
• Encrypting DNS queries end-to-end: There are ways of encrypting DNS traffic to prevent sniffing. DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) are incompatible and in their early stages, but both encrypt DNS queries between a stub resolver and a DNS server. This encrypted connection reveals nothing to outside parties. It’s like a VPN for DNS queries, with the same sorts of advantages. Cloudflare offers both, while Google Public DNS offers DoH, and Quad9 offers DoT.

Most of these capabilities exist independently of your apps or operating system. DNSSEC requires certificates at each level of the hierarchy and at the domain’s DNS host, but you’re not involved in making that happen.

Similarly, query name minimization requires no effort on your part. Cloudflare also uses a technique to reduce repeated queries for non-existent domain information (called “aggressive negative answers”) to help global infrastructure.

DoT and DoH require new stub resolvers in operating systems to offer their full benefit. You can get this advantage now by installing software that acts as a proxy for your system’s stub resolver. Test DoT by installing software named “stubby” on desktop platforms, including macOS. Cloudflare also offers a DNS proxy that provides DoH support for several platforms, but it’s complicated enough that installing is best reserved for more advanced users. (I’m not going to install it!) DoH could wind up embedded in individual applications, too, which would improve DNS security before operating systems catch up. The Mozilla Foundation has tests underway using DoH directly within Firefox.

Improving DNS Performance

As you might imagine from all the steps involved, DNS resolution can sometimes be slow, and even though individual lookups can be fast, they’re a gating item. Some lookups happen sequentially, as one resource loads another that requires more lookups, and tens of milliseconds start to add up to full seconds.

Over a decade ago, OpenDNS pioneered public DNS service with super-fast lookup times and showed that DNS improvements could provide a better user experience. (OpenDNS is now owned by Cisco and focused more on other areas, which is why I haven’t included it here.)

Performance is one of Cloudflare’s claims for its service. DNSPerf reports back that up: Cloudflare serves queries in 10-12 milliseconds, while Google Public DNS and Quad9 take more than 30 milliseconds to respond to a DNS lookup.

Those are the benefits, but we have to talk about the tradeoffs, too.

With DNS Lookups, Who Do You Trust?

Despite all the above improvements in protecting the security of your DNS queries against unwanted eyeballs, queries are entirely unencrypted and available at the DNS server on the other end of the connection. In other words, you need to trust the organization that runs that DNS server, since it will be able to see all your DNS lookups and associated information, such as the IP address and details about the stub resolver making the query. So who are Cloudflare and Quad9?

Cloudflare offers commercial and free protection against distributed denial of service (DDoS) attacks, a constantly increasing scourge in frequency and scale worldwide. It’s partnered with APNIC (Asia-Pacific Network Information Center), which owns the 1.1.1.1 and 1.0.0.1 IP addresses. Cloudflare provides an extensive privacy policy for its service, detailing the information it collects and what it destroys. The company will be sharing some data with APNIC, which will in turn analyze it and destroy the source material.

Some people are uncomfortable with Cloudflare, because of its long-running policy to not discriminate in any fashion against customers who deploy its anti-DDoS caching and re-routing service, even if it’s being used for hate and other extreme speech. Others have a problem with how Cloudflare’s CEO abruptly dropped several extreme sites with no warning or change in policy, just because he had changed his mind.

Cloudflare offers a few fairly extensive free services as marketing tools — it’s an efficient and no-pressure way for the company to reach small businesses who might later purchase premium offerings. (TidBITS currently uses Cloudflare’s free service to reduce the load on its main server.) Cloudflare also gains valuable aggregated intelligence about how DNS is misused (notably by Internet of Things devices) through the DNS queries it handles.

In contrast, Quad9 is a non-profit organization that has as founding partners IBM, Packet Clearing House, and the Global Cyber Alliance. It operates all its services for free as part of a mission of to minimize exposure and risk, but, much like Cloudflare, it’s also gathering aggregated information that will help its partners with threat awareness and mitigation. Quad9’s privacy policy is equally detailed. Adam Engst’s long experience with one of Quad9’s key people helped him place a lot of trust in its adherence to its policies.

Finally, we all know Google, and people have varying feelings about how Google uses data from individuals to drive its advertising business. The privacy policy for Google Public DNS says that the information passing to it isn’t used for other Google services. I use many Google services and Web apps, but I don’t use Gmail and I’ve grown increasingly concerned over time about how well the company’s statements match its actions, and how much it’s concerned about public relations and governmental consequences.

The fact remains, however, that your queries may not stay private when they arrive at any of these organizations — a hacker could infiltrate their systems, or a government agency could demand details or seize control. To be fair, that’s true of any DNS provider, including your ISP, which might be even less capable of fighting off technical or legal attacks.

It is not unreasonable to worry that a company might stretch the limits of what it has promised in its privacy policy and public statements, and sell details about you or use it to market products and services to you. We simply can’t afford blind trust anymore, given the many ways companies have abused our personal metadata.

Small Steps to a Better DNS

A team of Princeton University researchers has proposed Oblivious DNS, which would dramatically mitigate the possibility of connecting someone’s query with the results returned. Unfortunately, it would require new DNS infrastructure — something that’s possible only if people are willing to try new DNS servers in large quantities, and if operating system makers like Apple, Google, and Microsoft decide the benefits are large enough for their customers. Will that happen? Probably not, since DNS is so pervasive and embedded, it’s seems impossible to fix it comprehensively for everyone.

Nevertheless, every step you take toward greater security and privacy is a positive one. It’s important to think about where your data ends up, and only you can decide whether having your queries available to Cloudflare, Google, or Quad9 is an improvement over your existing exposure to your ISP, which may not employ any of the aforementioned DNS protections.

I also hope these high-profile public DNS services put more pressure on Internet infrastructure providers to roll out these improvements to DNS resolvers everywhere.