DNS troubleshooting: follow the evidence
A repeatable workflow for wrong addresses, missing records and SERVFAIL, with checks that distinguish DNS from hosting problems.
example.comA192.0.2.10192.0.2.20Write down the failure before changing anything
Record the exact hostname, the time, the network you are using and the error. “The website does not open” can mean a DNS error, a connection timeout or a TLS certificate warning. Those need different fixes. Save your current zone before editing it.
Step 1: ask for the record the service uses
For a website, query A and AAAA for both the root domain and www. For incoming email, query MX. For verification, query the provider’s exact TXT or CNAME name. A missing AAAA record is usually fine when IPv6 is not configured; a stale AAAA record is not.
dig example.com A dig example.com AAAA dig www.example.com CNAME nslookup -type=MX example.com 8.8.8.8
Step 2: classify the response
| Observed result | Investigate first |
|---|---|
| Wrong address | Active zone, recent changes and cached copies. |
| NXDOMAIN | Spelling, missing name and registrar delegation. |
| SERVFAIL | DNSSEC validation, unreachable nameservers and broken delegation. |
| NOERROR, no answer | The name may exist without the requested type. |
| Correct address, failed website | HTTP service, TLS, routing and firewall configuration. |
Step 3: compare a public resolver and the authority
mydnsreport.com queries public recursive resolvers. These may return cached data. To compare with the source of a zone, first identify its authoritative nameservers and then query one directly using a terminal. Use your domain’s real nameserver in the second command:
dig example.com NS dig @ns1.your-dns-provider.example example.com A +norecurse dig @8.8.8.8 example.com A dig @1.1.1.1 example.com A
If the authoritative answer is wrong, fix the active zone. If it is right but a resolver still has the previous value, compare the previous TTL and the time of the change. Flushing your computer’s cache does not flush a public resolver’s cache.
Step 4: verify the nameserver delegation
A zone can look correct in a hosting dashboard while the domain uses a different DNS provider. Check the nameservers configured at the registrar. Confirm that the delegated servers serve the intended zone. Nameserver changes and address changes are different operations; do not change both just to see what happens.
Step 5: investigate DNSSEC without hiding the failure
After a DNS provider change, a stale DS record at the registrar can cause validating resolvers to return SERVFAIL. Compare the new provider’s signing instructions with the registrar’s DS configuration. Do not interpret an absent AD flag as proof of an error, and do not use disabled validation as a production workaround.
Worked example: only some visitors reach the new site
Suppose an A record was moved but an AAAA record still points at the previous host. IPv4-only clients may reach the new server while IPv6 clients reach the old one. Query both types, compare them with the new host’s supported addresses and correct the stale record. In another case, both records may be correct at the authority but still cached elsewhere. The same symptom can have different causes.
Escalate with a useful evidence bundle
- The queried hostname and record type.
- Expected and observed values, plus the source of the expected value.
- The selected resolver and UTC timestamp.
- The previous TTL and the change time if known.
- The browser error and whether another network reproduces it.
Use the lookup tool to download a JSON response. Keep sensitive credentials out of tickets. For a planned move, use the cPanel migration checklist.
Technical references
RFC 1035 defines DNS message and record fields. RFC 2308 explains caching of negative answers.