Troubleshooting DNS errors: a step-by-step workflow

The instinct with DNS problems is to start editing records. Hold off — DNS failures get much easier to fix once you know which layer is lying to you. Before changing anything, record the exact hostname, record type, response, time, network, and expected value.

Identify the symptom

Run queries that preserve useful detail:

dig example.com A
dig www.example.com CNAME
dig example.com MX

Common outcomes include:

• NXDOMAIN: the queried name does not exist according to the answer path.
• SERVFAIL: the resolver could not complete a valid answer, often because of nameserver reachability, delegation, or DNSSEC validation.
• NOERROR with no answer: the name may exist but not have that record type.
• A wrong address: an authoritative record or a cache still contains an unexpected value.

Confirm registration and delegation

Check that the domain is active and not on a hold status. Then query nameserver delegation:

dig example.com NS +trace

Compare the nameservers returned by the parent zone with the provider that contains the intended records. If they differ, either update delegation at the registrar or edit the zone on the actually authoritative provider.

Query authoritative servers directly

Find the authoritative nameservers, then ask one directly:

dig @ns1.dns-provider.example example.com A
dig @ns1.dns-provider.example www.example.com CNAME

If different authoritative servers return different data or serials, the provider may have a zone synchronization problem. Do not compensate by repeatedly changing the record.

Compare recursive answers and TTLs

Query more than one recursive resolver and inspect TTLs:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

If authoritative DNS is correct and only some recursive answers are old, the likely cause is caching. Wait for the remaining TTL. Repeated edits can make diagnosis harder and may start new cache lifetimes.

Local cache flushing is useful only after public DNS is correct. On current operating systems, follow the platform’s supported cache instructions; do not assume one command applies everywhere.

Investigate SERVFAIL and DNSSEC

Use dig +dnssec and compare validating and non-validating paths. If a delegation signer (DS) record remains at the parent but the child zone no longer publishes matching keys, validating resolvers can return SERVFAIL.

Coordinate DNSSEC changes with the registrar and DNS provider. Removing records at random can make the domain insecure or extend an outage.

Stop when DNS is healthy

When authoritative and recursive queries return the expected values, DNS has done its job. Continue with network checks, TLS certificate coverage, HTTP response codes, redirects, and application logs.

curl -I http://example.com
curl -I https://example.com

If HTTPS fails while DNS resolves, use the SSL and HTTPS guide. If the issue began during a migration, use the DNS cutover runbook.

Sources and further reading

• RFC 1034: DNS concepts and facilities
• RFC 1035: DNS implementation and specification
• IANA: Root Name Servers