A single unreachable, mismatched, or stale nameserver can cause intermittent DNS failures even when your hosting server and zone records look correct. The issue may appear as a website that works on one network but not another, mail delivery failures, or a migration during which the domain resolves to both old and new IP addresses.
Run a symptom-first DNS decision tree
Run the checks below and identify the broken layer before changing any record.
Sort the error before touching DNS
Start with the visible symptom. A browser message saying “server DNS address could not be found” points to resolution, while an HTTP 502 or 503 means DNS may already be correct.
- NXDOMAIN means the queried name does not exist at the DNS layer.
- SERVFAIL often points to DNSSEC validation, a broken authoritative server, or bad delegation.
- Timeout means no usable reply arrived, often due to unreachable nameservers or port 53 filtering.
- Wrong IP usually means a stale A or AAAA record, a cache, or split-horizon DNS.
- Web works but mail fails means check MX and TXT records separately.
Query the name from your own network
Run these commands after replacing example.com with your domain. dig exposes the answer, authority, and TTL fields.
Bash
dig example.com A
dig example.com AAAA
dig example.com NS
host example.com
nslookup example.com
whois example.com
Trace the delegation path
Run the full trace before flushing browser caches or switching resolvers. This asks root, TLD, and delegated nameservers in sequence.
Bash
dig +trace example.com
dig +trace example.com NS
Use this order: inactive or expired domain → registrar issue; wrong NS at the TLD → delegation issue; NS does not answer SOA → authoritative issue; NS answers wrong A, AAAA, MX, or TXT data → zone issue; public resolvers disagree → cache or regional resolver issue; all answers are correct but the site fails → hosting, firewall, TLS, or application issue.
Use each tool for a distinct layer of DNS resolution rather than treating their output as interchangeable. A dig response with status: NOERROR, an ANSWER SECTION, and the aa flag when querying an authoritative server confirms that the zone answered directly; a DNS server timeout means no usable response arrived and should be retested with both UDP and TCP using dig @ns1.example.com example.com A +tcp. nslookup example.com and host example.com provide quick confirmation of the resolver’s selected address, while whois example.com helps identify registrar status and the TLD nameservers. traceroute does not trace DNS delegation; use it only after DNS resolution returns an IP and a network path problem is suspected.
When authoritative nameservers return the same data but public resolvers differ, the remaining cause is usually cache state or resolver behavior, not the zone itself.
Verify delegation, authority, and DNSSEC
Verify the parent delegation and authoritative answer to expose registry, glue, lame delegation, and DNSSEC faults.
Ask the TLD which nameservers it uses
For a .com domain, ask a .com server directly. The result shows the nameservers the registry has published, not what your hosting dashboard claims.
Bash
dig NS example.com @a.gtld-servers.net
dig +short NS example.com @a.gtld-servers.net
Confirm every server is authoritative
Query each delegated server for the SOA record. Each reply should have the aa flag, meaning authoritative answer, and matching SOA serials.
Bash
dig SOA example.com @ns1.your-dns-host.com
dig SOA example.com @ns2.your-dns-host.com
dig A example.com @ns1.your-dns-host.com
dig A example.com @ns2.your-dns-host.com
Test glue and DNSSEC separately
Check glue when nameservers sit inside the same domain, such as ns1.example.com; parent-side glue addresses break the circular problem of needing DNS to find the DNS server.
Bash
dig NS example.com @a.gtld-servers.net
dig A ns1.example.com @a.gtld-servers.net
dig +dnssec example.com
delv example.com
delv validates DNSSEC and is useful when normal dig shows an answer but validating resolvers return SERVFAIL.
DNS path: test each handoff
Registrar
Publishes NS
TLD
Delegates domain
Authoritative NS
Serves zone
Resolver
Caches reply
Device
Connects to IP
A failure at one box can make the next box look guilty. Query the prior box first.
Separate DNS from hosting and network faults
Compare DNS answers with direct server tests and stop blaming the hosting provider when the address is already correct.
Test the web server without DNS
Use curl --resolve to force a hostname to a known IP. This tests the web server while preserving the hostname required for virtual hosting and TLS.
Bash
curl -I https://example.com
curl --resolve example.com:443:203.0.113.10 -I https://example.com
curl -4 -I https://example.com
curl -6 -I https://example.com
If --resolve works but normal curl fails, return to DNS; if both fail, inspect the host, firewall, certificate, or origin service.
Find stale or broken AAAA records
Compare IPv4 and IPv6 replies before a server migration is completed. An AAAA record maps a name to an IPv6 address, while an A record maps it to IPv4.
Bash
dig +short A example.com
dig +short AAAA example.com
curl -4 -I https://example.com
curl -6 -I https://example.com
A common case is an old IPv6 address left behind after a move: IPv4 visitors load the site, but IPv6 users see timeouts because the old server no longer accepts traffic.
Read the service symptom correctly
| Observed result | Likely layer | First test |
| NXDOMAIN or wrong NS | Registrar or delegation | `dig +trace` |
| Correct IP, connection timeout | Host, VPS, firewall | `curl --resolve` |
| IPv4 works, IPv6 fails | Broken AAAA or IPv6 route | `curl -6` |
| TLS warning, DNS correct | Certificate or virtual host | `curl -Iv` |
Compare resolver caches and restore mail DNS
Query public resolvers and validate mail records separately to distinguish cached data from incomplete migration work.
Compare several resolver answers
Ask Cloudflare and Google Public DNS directly, then compare them with your authoritative server. Different public answers with a correct authoritative answer normally indicate caching, anycast routing differences, or a resolver incident.
Bash
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @ns1.your-dns-host.com example.com A
dig @1.1.1.1 example.com MX
Browser DNS over HTTPS can bypass the operating system resolver, so one browser may fail while command-line tests work.
| Prior TTL | Typical old-answer window | What does not speed it up |
| 60 to 300 seconds | 1 to 5 minutes | Editing the record repeatedly |
| 1 hour | Up to 60 minutes | Flushing another resolver |
| 4 to 24 hours | Up to the cached TTL | Changing nameservers again |
Check mail records one by one
Test mail after every DNS move, even when the website is loading. MX chooses the receiving mail server, SPF authorizes senders, DKIM publishes a signing key, and DMARC states how receivers should treat failed checks.
Bash
dig MX example.com
dig TXT example.com
dig TXT selector1._domainkey.example.com
dig TXT _dmarc.example.com
Resolve each MX hostname to A and AAAA records. Check for one SPF TXT record only, the correct DKIM selector from your mail provider, and a DMARC record that matches the intended rollout policy.
Confirm outbound identity after migration
Check reverse DNS if messages leave from a VPS or cloud IP. A PTR record maps an IP back to a hostname and is usually set by the IP provider, not by the registrar.
Bash
dig -x 203.0.113.10
Frequently asked questions
How do I troubleshoot DNS issues?
Run dig +trace example.com, then query each authoritative nameserver and at least two public resolvers. Fix the first layer that disagrees, rather than changing records at several layers.
Why does DNS work on one computer only?
One device may use a different cache, DNS over HTTPS setting, VPN, router, or split-horizon resolver. Compare dig @1.1.1.1 example.com with the affected device’s configured resolver before flushing anything.
How long does DNS propagation take?
It depends on the TTL cached before your change, which can range from 60 seconds to 24 hours. A new lower TTL does not shorten an old cached answer.
How do I fix a DNS server not responding?
Test another resolver first, then query the authoritative nameserver directly on port 53. If authoritative queries time out, check nameserver uptime, UDP and TCP port 53, firewall rules, and TLD delegation.
Why does my website work on IPv4 but not IPv6?
A stale or unreachable AAAA record is the common cause. Compare curl -4 -I and curl -6 -I; remove the AAAA only if IPv6 is not meant to serve the site.
Document the fix and watch the next change
Record the failing command, the exact reply, the changed record, its TTL, and the time of the edit.
Keep TTLs between 300 seconds and 1 hour before a planned migration when your traffic pattern permits it. Raise them again after the move is stable to reduce repeated resolver queries.
Test A, AAAA, NS, SOA, MX, SPF, DKIM, and DMARC from authoritative servers and public resolvers before closing a change window.
⚠️ Keep a copy of the prior DNS zone until public resolvers, IPv4 and IPv6 tests, and mail checks stay correct for at least one prior maximum TTL.
