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: 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.
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;
2606:4700:4700::1111
2606:4700:4700::1001
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 1.1.1.1 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
https://www.michaelhorowitz.com/DNS.and.Routers.March.2018.php
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
https://www.routersecurity.org/testrouter.php#DNSserverTests
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.
-Al-
To use DoT encryption your link to the instructions for installing stubby include this snippet:
tls_auth_name: âdns.quad9.netâ
tls_pubkey_pinset:
- digest: âsha256â
value: MujBQ+U0p2eZLTnQ2KGEqs+fPLYV/1DnpZDjBDPwUqQ=
If Iâm using CloudFlare, do I need to change the 9.9.9.9 to 1.1.1.1 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.
David
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
Stephen
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âŚ