Photo by Cloudflare
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.
- Open System Preferences > Network > Advanced > DNS
- Click the + button under the DNS Servers box. Enter the IP address of the first DNS server.
- 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.)
- Click OK, and then click Apply.
For the different services, the IP addresses to enter are:
- Cloudflare: 18.104.22.168 and 22.214.171.124 (see note below)
- Google Public DNS: 126.96.36.199 and 188.8.131.52
- Quad9: 184.108.40.206 and 220.127.116.11
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 18.104.22.168 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 22.214.171.124 address to reach the Web page and for DNS and omit the 126.96.36.199 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: 188.8.131.52 and 184.108.40.206.
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 (220.127.116.11) 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 18.104.22.168 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?
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.
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.
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.
If I change DNS on my iMac or iPhone, do I need to change it on my wi-fi router as well? In other words, does the DNS setting on my iMac or iPhone override the setting on my router? If not, I’m thinking I can just change the router DNS and not worry about changing it on individual devices.
Yes, router is easiest. Some proviso:
You can’t change it easily on an iOS device, as you have to change it network by network. So you could change it for your home and routine networks, but Adam Engst has seen these changes not stick, and revert to automatic DNS server assignment as provided by the network gateway.
If you set it on a router, you don’t need to do anything with the devices that connect to the network. However, you might choose to set DNS servers manually on a Mac laptop, as you might want to use those DNS settings when you’re off a network you have control over.
The DNS setting on my iMac or iPhone override the setting on your router. Changing it on your router, can make it less time consuming for those with multiple devices.
Some missing information that may solve some issues:
The IPv6 addresses should also be entered for Cloudflare in case your ISP uses them;
Some browser extensions that are linked to actual apps may fail to function properly after using the Cloudflare DNS. An example of this is the password manager, “SafeInCloud”. This is a browser issue, not the App as in Chrome the issue does not occur.
The simple fix is to add “localhost” into the “Search Domains” the same way you entered IP addresses into the “DNS Server” box after noting the current search domain and adding back in after you entered “localhost” into the search domain.
I personally would appreciate it if you did not add the ‘localhost’ fix into the Cloudflare knowledge base but instead refer them back to this Tidbits article or Apple support or Sonic ISP for assistance who have received this information. This are organizations that offer real support. Cloudflare’s only support is to refer users of the 22.214.171.124 to a community knowledge base which is essentially no company support, depending on users to fix issue by themselves. As such I prefer to direct users for support to organizations that offer real support and value their users time, effort, and contributions by offering actual support from the organization employees when it is needed and the information does not exist in self-service support tools.
Cloudflare looks interesting, but how does it compare with DNSCrypt?
I suspect that using both would be counterproductive, so is Cloudflare a better option than DNSCrypt, or are they just alternatives offering the same solution?
I think that DNSCrypt is a protocol that enables the provision of secure DNS. It is an alternative to DNS over HTTPS (DoH), which is what I believe Cloudflare uses. I don’t know how the two compare in practice, but DoH is a standard, I believe.
Do you have an opinion on DNSCloak? It seems like the easiest way to change the DNS on iOS, and the only way to use an alternate DNS for mobile data.
Some routers can over-ride the DNS servers that are set on your device. For more see
So, even a Mac with hard coded DNS for Cloudflare, may well use other DNS servers when at a public WiFi network. The good news is that you can test for this. A list of websites that tell you the DNS servers actually being used are here
If you override DNS settings on a Mac, my recollection is that it doesn’t apply any fo the DHCP-provided values. IPv6 responses are returned from IPv4 DNS servers, so that shouldn’t cause any issues to just use IPv4 addresses.
DNSCrypt was a proposal that never got folded into standards.
Interesting option, because from what I can see is it uses a profile, which allows it to do this override. I haven’t tested it. I’d rather see Cloudflare and Quad9 develop an iOS profile that you could just install, or a third-party developed a 99¢ or $1.99 app, the sole function of which was to let you switch between DNS providers.
Having tested DNSCloak, this seems to be what it is (except it’s free). It lets you choose (a) DNS provider(s) and then you can connect and override the DNS your phone was using. As you say, it does this via a (VPN) profile. I don’t know enough about networks to verify it’s behaving properly, but it looks like it’s working!
DNSCrypt provides secure DNS today, whereas neither of the secure services offered by Cloudflare have been implemented by Apple in macOS or Safari yet. As far as I know, the same is true for all 3rd party Mac browsers.
To use DoT encryption your link to the instructions for installing stubby include this snippet:
- digest: “sha256”
If I’m using CloudFlare, do I need to change the 126.96.36.199 to 188.8.131.52 and “dns.quad9.net” to some thing else?
Of course this all gets interesting if you set your DNS on the local device (laptop, phone, …) then try and connect via a WiFi that wants you to agree to some terms. Some (many) of them black hole all of your traffic until you ask for a web page. Then they put up their “check this box” or “log in with your credentials” page. They do this by re-directing all your DNS requests to the device they give you via DHCP to their internal authentication whatever. So email and web browsing just hang or gives odd errors until you turn off your custom DNS settings and then get the authorization page to load or reload. (If you browser fired up with those 3 windows and 40 tabs have fun finding the web page you need.) More and more authentication setups are getting better about making this all work without the hassles but the annoying ones are still plentiful.
And my wife is asking, “why can’t it just work” as we are in some airport concourse for the first and maybe only time in our lives.
I’m trying to test Cloudflare DoT encryption over Google Fiber using “stubby”. I keep getting the message “Could not bind on given addresses: Address already in use”. Any idea what I might be doing wrong? Thanks
Found my problem.
If the stubby daemon is running before I run a test, I have to kill it in Activity Monitor each time before I run it.
I also found that it will work with or without the tls_pubkey_pinset parameter.
Researchers have found some Chrome VPN extensions leaking DNS info…
Join the discussion in the TidBITS Discourse forum