Which DNS resolver should I use?

How to pick a DNS resolver, with the dig that shows each difference.

What a resolver does#

Every name your device looks up goes to one server, the resolver. It finds the answer by walking the delegation from the root (anatomy of a query), caches it, and hands it back. Unless you set one, your device uses whatever the network gave it: DHCP option 6 (RFC 2132 section 3.8), or the RDNSS option for IPv6 (RFC 8106 section 5.1). At home that is usually the router, which by default uses your provider's resolver (Apple).

$ dig -4 @9.9.9.9 example.com A

To see which resolver you use today, and whether anything rewrites its answers, run the two queries in test your own path.

What changes when you switch#

Most answers come back the same from any working resolver. Four things differ, and each one shows up in a dig.

Filtering. Some resolvers answer a blocked name with NXDOMAIN or 0.0.0.0 instead of its address, usually with Extended DNS Error 17, Filtered (RFC 8914). Same operator, two addresses, two answers:

$ dig -4 @9.9.9.9 isitblocked.org A

$ dig -4 @9.9.9.10 isitblocked.org A

DNSSEC validation. A validating resolver checks the signatures and refuses a forged or broken answer (RFC 4035 section 4.3). The status board reads each listed resolver's AD flag on a signed name, live.

$ dig -4 @1.1.1.1 dnssec-failed.org A

Who sees your lookups. A lookup on port 53 is plain text: the resolver operator sees it, and so can anyone on the path (RFC 9076). Changing the resolver's address changes who runs it; it hides nothing from your provider, and some networks answer port 53 themselves wherever you point it (step 1 of test your own path shows that). Only an encrypted setting on the device hides the lookup on the way: DNS over TLS (RFC 7858) or DNS over HTTPS (RFC 8484). Your provider still sees the addresses you connect to and, for most sites, the name in the TLS handshake (RFC 8744 section 1). What the operator keeps is in its own policy, linked in the table below.

Speed. The Query time line above is that resolver from where you sat. The latency on the status board is measured from our probes and the edge, not from your house; your own number is the dig you run yourself.

Is it worth switching?#

Keep the default if your lookups work, nobody on the network needs filtering, and you don't mind your provider seeing them.

Switch if one of these is true, and check it with the dig beside it:

Cloudflare and its filtered addresses#

Cloudflare runs three addresses, one per filter (Cloudflare):

$ dig -4 @1.1.1.3 nudity.testcategory.com A

$ dig -4 @1.1.1.1 nudity.testcategory.com A

The isitdns recommendation#

If your device or router takes more than one resolver, give it two, from two different operators, both encrypted. One operator's outage then does not take your lookups down with it.

Two limits, from the platforms' own documents:

• Give both the same kind of filtering. A resolver with a filter beside one without lets a blocked name through whenever the second one answers; Quad9: "We do not recommend mixing secured and unsecured service IP addresses in the same configuration" (Quad9).
• Some devices hold one encrypted resolver. Android's Private DNS takes one hostname (Android) and an Apple encrypted DNS profile names one server (Apple); there, pick one. Windows asks its list in order and moves on after a timeout (Microsoft).

On 2026-10-25 CleanBrowsing's security and family addresses, asked over port 53 and over DoH, answered dnssec-failed.org with an address where 1.1.1.1 answered SERVFAIL: on that date they did not check DNSSEC.

The status board reads these operators live (none of Control D's addresses above; of DNS4EU, only 86.54.11.1): up or down, latency from our probes, and the AD flag.

See also#

• How to check a resolver
• Resolver comparison: one name asked of several resolvers side by side
• DoT, DoH, DoQ: the encrypted transports
• DNSSEC, signed and validated
• Extended DNS Errors: what EDE 9 and 17 mean