Debug a DNS failure

“The site is down, it must be DNS.” Sometimes. Often it’s something else wearing a DNS costume. The way to find out is a fixed sequence, top to bottom, with no edits until you have evidence.

The sequence

Work through these layers in order:

1. Name. Copy the exact failing hostname. example.com and www.example.com are different names with different records.
2. Question. Which record type does this need? A, AAAA, CNAME, MX, or TXT.
3. Delegation. Run dig +trace to see where the parent zones send the lookup.
4. Authority. Ask a listed authoritative server directly with +norecurse.
5. Cache. Compare the authoritative answer with public resolvers and your local one.
6. Connection. Does the returned address accept connections on the needed port?
7. TLS. Check the certificate name, its validity, and the proxy TLS mode if there is one.
8. HTTP. Look at the status code, the redirect target, and what the application returns.

Stop at the first layer that fails. That’s where the fix goes.

The commands

Here’s the set I run, in order:

dig +trace www.example.com A
authoritative_server=$(dig NS example.com +short | head -n 1)
dig @"$authoritative_server" www.example.com A +norecurse
dig @1.1.1.1 www.example.com A
curl -Iv https://www.example.com/

The trace covers delegation. The direct query covers authority. The 1.1.1.1 query covers caching. curl -Iv covers connection, TLS, and HTTP in one shot, with the handshake details printed.

Read the status precisely

Each DNS status means one thing:

• NXDOMAIN: the name doesn’t exist
• NOERROR with an empty answer: the name exists but has no record of this type
• SERVFAIL: broken authority or failed DNSSEC validation
• timeout: the server didn’t answer, so network or reachability

Different resolvers giving different answers with TTLs counting down? That’s caching, and it will resolve itself.

When DNS is right, stop editing DNS

This is the rule I’d tattoo on people. If authority and resolvers agree and the address is right, DNS is done. Editing more records won’t help and may add new caching problems.

A certificate name mismatch is a TLS problem. A 502 from Cloudflare means the client reached the proxy but the proxy couldn’t reach your origin. A redirect loop right after enabling the proxy is almost always the origin and the proxy disagreeing about HTTP versus HTTPS. Fix the TLS mode, not DNS.

Test a candidate origin without touching DNS

When you want to check a new server before pointing DNS at it, use curl --resolve. It sends the request to the address you choose while keeping the real hostname. No hosts-file hacks, no waiting for caches, no risk to visitors.

Try this: build a worksheet for one hostname with one row per layer. In each row put the command, what you observed, what you expected, and who owns the fix if that layer fails.