🔎 How to check a resolver

resolver: the server your machine asks first

$ dig @1.1.1.1 isitdns.net SOA

Step 1: find which resolver you use#

The setting you configured is not always the one in use.

Look for the nameserver line. That is who your machine asks. On modern Linux that is often 127.0.0.53, a local stub, not a real remote server; resolvectl status shows what it forwards to.

Browsers can run their own DoH (RFC 8484 section 1) and bypass this setting entirely. If a name works in the terminal but not the browser, or the other way around, that is why. See dot-doh.

Step 2: does it answer?#

Ask it something simple:

dig @1.1.1.1 isitdns.net A +short

Swap 1.1.1.1 for your own resolver's IP. Real output:

104.21.56.211
172.67.155.242

Reading it: two IPv4 addresses, so the name resolves. Two is normal; many services publish several addresses so clients can try another if one fails.

If nothing comes back, work through the header line instead, which +short hides. Run it again without +short and read the status: word:

Step 3: is it telling you the truth?#

A resolver that answers is not necessarily a resolver that is honest. The test is to ask several and compare.

for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo "$r -> $(dig -4 @"$r" +short isitdns.net A | tr '\n' ' ')"
done

What you want: the same set of addresses from each, allowing for order changes and for large services that legitimately vary by location.

A network between you and the resolver can intercept port 53 and answer in the resolver's name; preventing exactly that is a stated goal of DoH (RFC 8484 section 1). Confirm over an encrypted transport, which that network cannot forge:

dig @1.1.1.1 +https +dnssec isitdns.net A

If +https shows ad and the plain UDP query does not, something on the path answered for the resolver or rewrote its reply (RFC 2694). See dot-doh.

If one differs sharply, especially by returning a single address on a private range like 192.168.x.x or 10.x.x.x when the others return public addresses, that resolver is rewriting answers. That can be deliberate (split horizon, parental filtering, enterprise blocking) or hostile.

If all three agree with each other but disagree with what you get without @, the thing rewriting answers is between you and all of them. See the interception check on the troubleshooting index.

Step 4: confirm it is a resolver, not an authority#

A resolver does the lookup work for you: RFC 1034 §2.4 calls resolvers "programs that extract information from name servers in response to client requests". An authoritative server owns a zone and answers only for that zone.

dig @1.1.1.1 isitdns.net SOA

Check the flags line:

• ra present: recursion available, this is a resolver and it will do work for you
• aa present: authoritative, this server owns the zone the name is in. A server can set both; read ra for the recursion question and aa for the ownership one

An authoritative-only server does not recurse (RFC 1034 §4.3.2, step 1), so a machine pointed at one can look up names in that one zone and nothing else. Details in query-types.

Quick reference#

See also#

• check-a-forwarder: when your resolver hands queries onward
• nslookup-and-dig: tool comparison
• anatomy-of-a-query: the full journey of one lookup
• Resolver comparison: one name at four public resolvers, side by side