Why check a DNS zone before launch
Checking a DNS zone is not a formality — it lets you see the zone through a resolver's eyes instead of the control panel's. The hosting panel shows what is stored in the database, while dig shows what the authoritative servers actually return. The gap between these two pictures is the most common reason for a site being unreachable or mail not arriving a day after a configuration change.
Run the check in three cases: right after changing records, after moving to new NS servers, and before publishing any new domain to production.
The dig command: how to read the server's answer
Basic syntax: dig NAME TYPE. To fetch a domain's A record, run:
dig example.com A +shortThe +short flag strips the service output and leaves only the IP addresses. For the full picture with TTL, flags and the AUTHORITY section, drop it:
dig example.com MXThree blocks in the answer matter: the ANSWER SECTION with the actual records, the AUTHORITY SECTION showing which NS servers are treated as the source, and the line flags: qr rd ra; — if it lacks ra (recursion available), the server does not resolve recursively and you likely queried the wrong server.
To ask a specific server directly, bypassing the local resolver cache, target it with @:
dig @8.8.8.8 example.com AHow to check delegation and NS servers
Delegation itself needs a separate check — whether the parent zone (the domain registry) actually knows your NS servers. The command:
dig example.com NS +traceThe +trace flag walks the path from the root servers to the authoritative ones, showing every delegation step. If the NS list diverges from what you see in the registrar panel at some step, that is the source of the problem: the registry still stores the old servers, or the zone on the new servers has not been set up yet. This matters especially after delegating a subdomain to separate NS servers.
Compare the answer at the parent zone level and at the authoritative server level:
dig example.com NS @a.gtld-servers.net
dig example.com NS @ns1.example.comIf the lists do not match, synchronization has not finished yet — wait or check with the registrar.
dnsviz: visual verification of the DNSSEC chain
For DNSSEC, dig alone is not enough — the chain of trust is easier to inspect in dnsviz. The online version builds a zone graph and highlights breaks: a missing DS record in the parent zone, an expired RRSIG signature, or an algorithm mismatch. To run the check locally:
pip install dnsviz
dnsviz probe example.com | dnsviz printRed nodes on the graph are specific chain errors — start diagnosis from them instead of guessing again.
Common errors when checking a zone
Most problems fit a handful of recurring scenarios:
| Symptom in dig | Likely cause |
|---|---|
| SERVFAIL on every query | Broken DNSSEC chain or the zone is not responding |
| NXDOMAIN for an existing domain | Typo in the name or the zone is not published yet |
| Different answers from different NS | Records are not synchronized between servers |
| No ANSWER section, only AUTHORITY | Wrong record type requested or delegation is broken |
Checklist before publishing a domain
- Check A, AAAA and MX with
dig +short— values match the panel. - Verify NS with
dig NS +trace— the parent and the authoritative servers agree. - If DNSSEC is enabled, run the domain through dnsviz and clear every red node.
- Query at least two public resolvers (for example, 8.8.8.8 and 1.1.1.1) to rule out a local cache.
- Repeat the check 30 to 60 minutes after changes — some data still lives in the TTL cache.