Debug a DNS failure

Start with the exact hostname and record type. Check registration and delegated nameservers, then trace the lookup.

Do not begin by changing records. Collect evidence from the top down:

1. Name: copy the complete failing hostname. example.com and www.example.com are separate.
2. Question: identify the required A, AAAA, CNAME, MX, or TXT record type.
3. Delegation: use dig +trace to see where the parent sends queries.
4. Authority: ask a listed authoritative server directly with +norecurse.
5. Cache: compare the authoritative answer with public and local recursive resolvers.
6. Connection: test whether the returned address accepts the required port.
7. TLS: inspect certificate name, validity, and proxy TLS mode.
8. HTTP: inspect the status, redirect location, and application response.

Useful commands are:

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/

Interpret the response precisely. NXDOMAIN means the name is missing. NOERROR with no requested records is no-data. SERVFAIL can indicate broken authority or DNSSEC validation. A timeout suggests a network or server reachability problem. Different answers with decreasing TTLs suggest caching.

If DNS is correct, stop editing DNS. A certificate mismatch belongs to TLS. A 502 from a proxy means the client reached the proxy but it could not complete the origin request. A redirect loop after enabling a proxy is usually an HTTP or TLS-mode disagreement.

When public DNS is intentionally unchanged, test a candidate web origin with curl --resolve. This isolates the new endpoint without poisoning local DNS or waiting for caches.

Your action is to create a diagnostic worksheet for one hostname with one row per layer. Include the command, observed evidence, expected evidence, and next owner for a failure at that layer.