Choosing a DNS resolver

What a recursive resolver actually does for you, and what to look at before you point your devices at one

Overview

Every connection your device makes starts with a DNS lookup. The resolver that answers it sees the name of every site and service you use, decides how quickly you get an answer, and can decide whether you get an answer at all. Most people never choose one; they use whatever their ISP or network hands out. That is a reasonable default, but it is still a choice, and it is worth knowing what you are trusting the resolver with.

This post is about how to evaluate a resolver, not which one to pick. The questions below apply to your ISP’s resolver, to a public one, and to one you run yourself.

What a resolver knows

A recursive resolver receives the full name you are looking up, together with your IP address, for every lookup your device makes. Over a day that is a complete list of the sites, apps and background services you used, with timestamps. Whether that record is kept, for how long, and who can see it is the first thing to find out. Read the privacy policy for the words log, retain and share, and notice what it does not say.

The resolver also knows your approximate location from your IP address, and some forward a truncated form of it to authoritative servers to pick a nearby content server. That is a trade-off between speed and privacy that you should at least be aware of.

What to look at

  1. Logging and retention. Does the operator keep query logs at all? If so, for how long, and are they tied to your IP address? A clear statement beats a vague one.

  2. Business model. Running a resolver costs money. If you are not paying, understand what is. Advertising, data sales and “security intelligence” products all depend on query data.

  3. Filtering. Some resolvers block advertising, tracking, malware or adult content by returning no answer for those names. This can be exactly what you want. It also means the operator decides what you cannot reach, so look for a published policy on how the lists are built and how to report mistakes.

  4. Encrypted transport. Plain DNS travels in clear text, so anyone on the path can read or alter it. DNS over TLS and DNS over HTTPS encrypt the connection between your device and the resolver. Most current operating systems support at least one of them; check that the resolver does too.

  5. DNSSEC validation. A validating resolver checks the signatures on signed zones and refuses forged answers. It does not protect privacy, but it protects integrity.

  6. Speed and reliability. Latency is set mostly by distance to the nearest resolver node and by how warm its cache is. Measure it from where you actually are rather than trusting a benchmark from somewhere else. Anycast networks with many nodes tend to be both fast and resilient.

  7. Jurisdiction. Where the operator is incorporated and where the servers run determine which laws apply to your query data.

  8. Reversibility. Changing resolvers should be a few fields in your network settings, and clearing them should put you back on the default. Avoid anything that requires an agent or app for a basic resolver change.

How to check what you are using

It is common to configure a resolver and still be using a different one, because a VPN, a router, or an operating system feature took over. Two quick checks:

  • My IP Address shows the public IPv4 and IPv6 addresses your traffic leaves from.
  • My Resolvers shows which resolvers are actually answering your lookups, which is the only way to know whether your configuration took effect.

From a terminal, dig or nslookup against a specific server tells you what that server answers, and comparing it with a lookup that uses your system default tells you whether they agree:

dig example.com +short
dig @203.0.113.53 example.com +short

References