A DNS error and an HTTP error happen at different stages. If you received an HTTP 403 or 503 for the request, something answered it; do not assume that changing DNS will resolve that response.
Capture the name and the error
Write down the exact hostname, including any subdomain. example.com and www.example.com can have different records. Also record when the failure happened and which network you used. The browser’s error text is useful evidence; “the site is down” discards that detail.
Start with the DNS lookup tool or the commands below. These are read-only lookups for public DNS records. An internal hostname may deliberately resolve only through an organisation’s resolver, so asking a public resolver about it is not a test of the internal setup.
Compare like-for-like answers
On a system with dig, run the same name and record type against your configured resolver and two public resolvers:
dig example.com A
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com AAAA
dig @8.8.8.8 example.com AAAAOn Windows, nslookup example.com uses the configured resolver; nslookup example.com 8.8.8.8 queries that specified resolver. A command can time out if your network blocks external DNS. Record that transport failure rather than treating it as a DNS answer.
For a DNS-over-HTTPS comparison, this public URL returns Google’s structured response:
curl --max-time 10 'https://dns.google/resolve?name=example.com&type=A'Read the JSON Status, answer records and record types. An HTTP 200 from the resolver means the API responded; it does not by itself mean the DNS lookup succeeded. Google documents these fields in its DNS JSON API reference.
Interpret the difference before changing anything
| Observation | Next step |
|---|---|
| NXDOMAIN | Check spelling and the exact hostname. The resolver reports that the name does not exist; compare another resolver and the authoritative response before deciding why. |
| NOERROR with no AAAA answer | Check A as well. Lack of an IPv6 address is not proof that the name is absent or that IPv4 access fails. |
| SERVFAIL | Save the full answer and compare resolvers. For a domain you manage, inspect authoritative DNS and DNSSEC configuration rather than assuming a missing record. |
| Different addresses | Compare CNAME chains, record type and resolver location. Different answers may be intended. Test whether the returned destinations actually fail. |
| Timeout | Check whether a DNS response arrived at all. A blocked resolver path is different from NXDOMAIN. |
Avoid treating “propagation” as a diagnosis
After a record change, record what changed, when, and the old and new values. A cached answer can persist until its lifetime expires. Negative answers can also be cached; repeated NXDOMAIN responses immediately after adding a name may therefore need a different investigation from an incorrect authoritative record. Negative caching is specified in RFC 2308.
There is no useful universal wait time for your incident. Compare the current answers and their remaining TTL values, then recheck after a relevant interval. Repeatedly editing the same record changes the experiment and makes it harder to tell which configuration you are observing.
For domain owners: compare the source of the answer
dig example.com NS
dig example.com SOA
dig +trace example.com AThe trace follows the delegation path from your network. It may fail where direct DNS queries are filtered, so it is supporting evidence, not a substitute for resolver comparisons. Check that the delegated nameservers are the intended ones and ask your DNS provider to investigate with the exact command output. Do not remove DNSSEC or switch nameservers as a general troubleshooting step.
What WebsiteDown does with DNS signals
Our host checker performs DNS diagnostics after an HTTP attempt fails. It queries A and AAAA at two public resolvers. Its current “DNS unreachable” rule groups several missing-answer states together, including SERVFAIL and empty answers. That label does not claim that the domain is unregistered or identify which authoritative server failed. Inspect the diagnostic states in the downloaded JSON.
If a subsequent HTTP test succeeds, DNS resolution alone is no longer the explanation for every remaining symptom. Continue with the exact-page and browser checks. The methodology documents the checker’s request and cache behavior.
Useful escalation data
Hostname and record type:
Time in UTC:
Resolver used:
Response status:
Answer / CNAME chain:
TTL observed:
Result from second resolver:
Authoritative response, if available:
Recent DNS change and change time, if known:
HTTP or browser outcome:Retain the full output locally. Remove internal names or addresses before sharing publicly. A precise resolver comparison gives your DNS provider something reproducible to investigate.