🔧 Troubleshooting: start here

Something is broken. You think it might be DNS. This section is the order to check things in, and the exact command for each check.

The whole method, in one idea#

Almost all DNS triage is one move repeated four times: ask each layer directly, and find the first one that gives you a different answer.

you  ->  your resolver  ->  the forwarder  ->  the authority
 |            |                  |                 |
step 1      step 2             step 3            step 4

Normally your machine asks one resolver and that resolver quietly does the rest of the work for you. When something is broken, you stop letting it do that. You go and ask each box yourself, in order, and compare what each one says.

The first box that gives a wrong answer is where the problem is. Everything to its left is fine. That is the whole technique.

Why asking directly works#

Every dig command below has an @ in it, like dig @1.1.1.1. That @ means send this question to exactly this server and nobody else. It skips your normal DNS settings entirely.

That matters because the usual reason DNS looks insane is caching. Something in the middle is holding an old answer, and you cannot see which thing. When you ask each server directly, you take the middle out of the picture and get each one's real opinion.

Which page you want#

Read this before you trust any output#

If your network intercepts DNS, every command on every page below can lie to you, and it will look completely normal while doing it.

Here is how to catch it in one command. Ask a server that cannot possibly exist. 192.0.2.99 is from a block reserved by RFC 5737 specifically for documentation, so no real nameserver lives there:

dig @192.0.2.99 isitdns.net SOA +time=3 +tries=1

What you should see: a timeout, and no servers could be reached. Nothing is there, so nothing answers.

What it means if you get an actual answer: something on your network is grabbing every DNS query you send and answering it itself, no matter who you addressed it to. This is common on home routers, guest wifi, corporate networks, and some ISPs.

Here is the real thing, captured from a machine whose network does this:

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
isitdns.net.		2350	IN	SOA	coleman.ns.cloudflare.com. dns.cloudflare.com. 2410489729 ...

An address that hosts no nameserver returned a full answer. Reading it piece by piece:

• flags: qr rd ra: ra means "recursion available", which is something a resolver says. A real authoritative server would never set it. So a resolver answered, not the server you addressed.
• 2350: that is the TTL, the number of seconds this answer stays valid. It is counting down, which means the answer came out of a cache. Fresh answers from an authority start at the zone's full TTL and do not sit at an arbitrary number like 2350.

The same query from a network that does not intercept returns what it should:

;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
isitdns.net.		1800	IN	SOA	coleman.ns.cloudflare.com. dns.cloudflare.com. 2410489729 ...

• aa is there. That means authoritative answer: "I own this zone, this is my own data" (RFC 1035 §4.1.1).
• No ra, because a pure authoritative server does not do recursion for you.
• TTL 1800, the zone's actual configured value, not a countdown.

If your network intercepts, do your testing from somewhere that does not: a phone on cellular, a cloud box, or an encrypted transport like DoT or DoH, which interception on port 53 cannot touch.

See also#

• dig-phonebook: every command in this wiki, sorted by what you want to see
• dig-flags: what each +flag actually changes
• anatomy-of-a-query: what happens between you and the answer