Why is my domain not resolving?

Step 1: registration and delegation

Look up the domain's registration (Website Recon or an RDAP client shows it). A domain with a serverHold or clientHold status is left out of the TLD zone and returns NXDOMAIN everywhere. Expiry on its own works differently: during the registrar's grace period an expired domain may keep resolving, or be pointed at a parking or renewal page, until the registrar interrupts it or the registry deletes it. So check the actual delegation in the next step rather than judging from the dates. See domain status codes and domain expiration and deletion.

Then ask the TLD which name servers it delegates to:

$ dig +norecurse @a.gtld-servers.net example.com NS

For a TLD other than .com or .net, list its servers first (for example dig org. NS) and ask one of those instead.

Step 2: the authoritative servers

Ask each name server from the previous step directly, without recursion. In the examples, replace ns1.example.net with a real server from that list:

$ dig +norecurse @ns1.example.net www.example.com A

An authoritative reply with the requested data shows that server answered that query correctly. A response without authority can indicate lame delegation; REFUSED can instead reflect an ACL, SERVFAIL has several causes, and a timeout establishes only that no response reached you on that path. Repeat against each listed server and inspect SOA, delegation, DNSSEC and reachability before diagnosing the cause.

Step 3: the record itself

• Check the exact name. example.com and www.example.com are separate records.
• Follow any CNAME to its end. A CNAME that points to a deleted name gives NXDOMAIN; a loop gives SERVFAIL.
• A CNAME cannot share a name with other records, and should not sit at the zone apex. See CNAME at the zone apex.

Step 4: DNSSEC

If a validating resolver returns SERVFAIL but the same query with checking disabled works, DNSSEC is broken:

The usual cause is a DS record at the registrar that no longer matches the zone's keys. See debugging DNSSEC validation errors.

Step 5: caches and the local network

An old recursive answer may be cached; wait for its remaining TTL only after confirming the zone, delegation and validation are healthy. Different public and local resolver results can also expose domain-side DNSSEC or authoritative reachability faults. Compare full replies and every authoritative server before deciding where to fix the issue. See Why DNS works on one network and not another.

How DNS Panopticon helps

Domain Visualizer looks the domain up through a public resolver and reports the problems it can see from there: no NS records, a name server host with no address, no A or AAAA record at the apex, a CNAME loop or a long CNAME chain on www, and DNSSEC that is broken or not validating. It does not query each authoritative server or test from your network, so use the commands above for those steps. Website Recon shows the registration, expiry date and status codes.