As the first step that must take place before connecting to a website, the Domain Name System (DNS) is an important lever to improve performance, as well as security. Many enterprises choose to run and manage their own recursive resolver for internal users, as this limits the sharing of data with a third-party system and enables them to leverage the DNS for enhanced security. Some enterprises use services like Cisco Umbrella and InfoBlox to set up fine-grained policies that leverage response policy zone (RPZ) feeds (InfoBlox) or a built-in threat list (Umbrella). But for those administrators who choose not to set up internal DNS for all enterprise sites or users — perhaps due to resource or management constraints — a public resolver may be a better choice than the default service DNS provided by a local Internet service provider (ISP).
The right resolver can be the difference between a fast web experience and maddeningly slow performance that can render cloud-based applications unusable. Luckily, multiple public DNS resolvers offer excellent performance, as we covered in our recently published Global DNS Performance Benchmark Report. In the report, we measured the performance of ten public recursive DNS resolvers. If we narrow this list to the top five performers across both IPv4 and IPv6, we’re left with five providers, each of which performed well across most global regions:
- OpenDNS (Cisco)
Given the number of high-performing providers, you may want to make your selection based on a broader set of criteria, depending on the needs of your organization. Some organizations may have stringent policies around what can be shared externally and with whom, so understanding how resolver operators handle query data may be as critical as knowing how each of these resolvers performs. DNS-based content filtering can also play a role in a broader security or policy-enforcement strategy, protecting users from harmful or banned content. The remainder of this post will focus on three aspects of public resolvers you should be aware of — privacy, the category of resolver operator, and content filtering.
Are my Queries Private?
Privacy is a weighty subject and in the case of resolvers covers multiple facets, including:
- Privacy over the network to the resolvers
- Privacy at the recipient resolver
- Privacy to the authoritative nameserver
A combination of technologies and policies dictate how each of the resolver operators approach these privacy domains.
Privacy to Resolver
Encryption of DNS queries ensures that your browsing data is safe from in-transit snooping. DNS over HTTPS (DoH), DNS over TLS (DoT) and DNSCrypt are three encryption mechanisms, each of which works slightly differently. An explanation of these mechanisms is beyond the scope of this post; however, what should be noted is that none of them are easily implemented by the average (non-technical) web user. Leveraging them requires some technical know-how and time spent in a command line, which may not be feasible to implement and enforce for large numbers of users.
There’s one exception to this, and it’s an implementation that is somewhat controversial. Mozilla Firefox partnered with Cloudflare earlier this to provide in-browser DoH via Cloudflare’s 18.104.22.168 public DNS service. When browsing via Firefox, this implementation overrides the DNS resolver set at a system-level, which some observers have compared to DNS hijacking. Assuming you’re aware of who’s handling your users’ queries (Cloudflare), and you’re okay with this arrangement, this could be a good option for over-the-network privacy. With virtually no setup required, queries will be masked as HTTPS traffic.
Regardless of which public resolver you choose (or even if you’ve chosen to set up an internal resolver), you should understand that Firefox’s DoH initiative with Cloudflare will circumvent whatever DNS settings you’ve implemented — unless this traffic is explicitly blocked. Depending on your organization’s policies and level of control required, you may want to consider taking that action.
Privacy at the recipient resolver
Privacy at the resolver is perhaps the most challenging aspect of query privacy to address. Not every public resolver operator is transparent on what if anything they store in the way of user data. Some public resolvers have policies around data purging, but precisely what is getting purged versus retained is unclear. Personally identifiable information may get scrubbed, but ultimately, the value in query data may be in the aggregate, as it can reveal rich insights into broader Internet browsing trends.
We’ll come back to the implications of query data collection later in this section.
Privacy to Authoritative Nameservers
Some resolvers have adopted techniques to limit the sharing of data with the various DNS servers they query to get an authoritative response. QName minimization is a way to truncate the record requested so that the full query is concealed from all parent zones. The idea is to share the minimal level of data required with each level of DNS hierarchy to prevent data leakage or in-transit exposure. Another way to limit the sharing of end-user data is not to enable EDNS client subnet (ECS), since ECS passes on the subnet data of the querying user to the authoritative nameserver.
The handoff of user geolocation via ECS from the resolver to authoritative is not just a question of privacy, but performance. If you’re running a local resolver, it’s irrelevant. But if you’re using an external resolver, either with your ISP or a publically available one, then it could have an impact. Some domain operators use DNS to steer users to the closest available web server so that they’ll experience the fastest possible performance. If an authoritative nameserver doesn’t receive a client subnet from the resolver, it will provide a record based on the location of the resolver. Depending on the distance between the client and the recursive resolver, this could lead to suboptimal performance connecting to the requested domain. You’ll want to weigh your concern about sharing location information with authoritative servers against the potential impact on performance for some websites.
Ultimately, there are no easy answers when it comes to privacy. If privacy in network transit is crucial to you — perhaps because you know or have reason to expect that your users’ queries may be intercepted, you have options. If you care about how much data your resolver shares with other DNS servers, you have options (though this is based on resolver policy and can change). If you want personally identifiable data purged, you have options. But if you have an objection to your organization’s data getting rolled into a big ol’ data lake for commercially-motivated digestion, your options are less clear, and, ultimately, come down to your organization’s willingness to extend trust to a resolver operator that could stand to benefit from collecting web data — perhaps even your organization’s web data.
Circumventing large-scale tracking and dissection of web user behavior is almost impossible. But what makes DNS query collection (on a massive scale) particularly interesting, is that it’s a fairly lightweight method to collect the browsing habits of large swaths of Internet users. DNS resolvers are strategically positioned to capture web user data, making them a perfect collection vehicle.
To be clear, most public resolver operators claim good intentions in offering a free service to the general public, and likely have no hidden malicious intent, but there are infrastructure and management costs associated with running a global high-performing service, so it’s legitimate to question the motivations of the entity providing it. Which brings us to our next decision factor — the nature of the resolver operator.
Who is Processing My Queries?
Each of the resolver operators we examined make claims about their service (level of privacy, etc.), but given the enormity of information that public resolvers are privy to, you may want to consider the operator’s core business as a clue to its motivations, which could be useful in determining whether to trust them with your queries.
The top five public resolver operators are a mix of commercial and non-commercial entities, as shown in figure 2.
Can I block unwanted sites?
DNS can be an effective way to block specific categories of websites, and some public resolvers offer one or more content filtering options. Depending on your organization, you may want to leverage some of these options to implement your security policies.
While Google and Cloudflare are fully open resolvers, OpenDNS and Quad9 both block known malicious sites (malware, phishing, etc.). CleanBrowsing goes further, specializing in family-friendly browsing and offering multiple filtering tiers, including malicious, adult, or any site not considered child-friendly, such as Reddit. CleanBrowsing will even force YouTube and other services into child-friendly mode to block backdoor access to sensitive content. The service is free and requires virtually no technical skills to set up, making it a compelling option for schools, libraries, and other environments that have more stringent content restrictions.
Putting it all together
The choice of public recursive DNS resolver can be reasonably complex once you factor in all of your criteria. Consider your use case, weighing your preferences against possible tradeoffs. For example, if your principal concern is performance, perhaps because you have a remote office that uses many SaaS applications, you might choose Google or Cloudflare. If you prefer to avoid a resolver operator with a conflicting commercial interest, you might select Quad9. Or if you’re the administrator for a school system, you might choose CleanBrowsing.
The DNS landscape is continuously changing, with the introduction of new operators and potentially evolving policies. It’s important to stay aware of these changes if you care about the state of a foundational Internet system. Subscribe to our blog to stay up to date on DNS and other topics related to Internet performance and digital experience.