DNS: CNAME and other data (CNAME at the zone apex)

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

# The loader names the offending record, so start with it
named-checkzone example.com /etc/bind/db.example.com

# Wrong: the apex already carries SOA and NS
# example.com.   IN CNAME  lb.provider.net.

# Right, depending on what the provider offers at the apex
# example.com.   IN ALIAS  lb.provider.net.     (PowerDNS and similar)
# example.com.   IN A      203.0.113.10         (the address itself)
# Route 53 uses an A record with an AliasTarget, Cloudflare flattens the CNAME

# Subdomains are unaffected, only the apex is special
dig www.example.com CNAME +short

# Check nothing already shares the name before adding a CNAME
dig api.example.com ANY +noall +answer

# TXT records for domain verification at the apex are the usual collision
dig example.com TXT +short

How to diagnose DNS errors

DNS errors are best diagnosed by working down the delegation chain: root, TLD, authoritative nameserver, then the record itself. The most common mistake is testing only through your local resolver, which caches both good and bad answers and hides where the failure actually is. NXDOMAIN means the name definitively does not exist; SERVFAIL means the resolver could not get a valid answer, which is usually a DNSSEC or authoritative-server problem, not a typo.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

1. Query the authoritative nameserver directly, bypassing all caches: dig @ns1.example.com example.com A. If that answers correctly, you have a caching or propagation issue, not a records issue.
2. Trace the full delegation with dig +trace example.com. This shows exactly which level of the hierarchy stops returning answers.
3. Distinguish NXDOMAIN from SERVFAIL from timeout. They have three entirely different causes. Check the status: line in dig output.
4. For SERVFAIL, test with DNSSEC validation disabled: dig +cd example.com. If that succeeds, the problem is a broken DNSSEC chain, often after a key rollover.
5. Check TTLs before declaring propagation broken. A record with a 24-hour TTL genuinely will not update for resolvers that cached it, and there is no way to force them.

Tools worth reaching for

• dig +trace
• dig @authoritative-ns
• dig +cd (DNSSEC bypass)
• kdig
• resolvectl status

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

📖 datatracker.ietf.org 📖 bind9.readthedocs.io

Related DNS errors

• Bad Gateway - DNS resolutionReverse proxy cannot resolve the upstream server's hostname to an IP address.
• dig: ;; Truncated, retrying in TCP modeThe answer did not fit in the UDP message size the client offered, so the server set the TC…
• dig: status: SERVFAIL with EDE: 6 (DNSSEC Bogus)The resolver fetched the answer but its DNSSEC signatures did not validate, so it refused to…
• DNS cache poisoning detectedDNS resolver returned suspicious results, possibly indicating cache poisoning attack.
• DNS lookup timeoutDNS query took too long to complete, often due to slow or unresponsive DNS servers.
• DNS NXDOMAINDomain name does not exist in DNS, the queried domain is not registered or configured.
• DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.comLet's Encrypt queried the authoritative servers for the DNS-01 challenge record and was told…
• DNS resolution failedThe domain name could not be resolved to an IP address. DNS server may be unreachable or the…

See all 20 DNS errors →

Browse other categories

• HTTP 494xx client errors, 5xx server errors, redirects, headers and protocol problems.
• JavaScript 42npm resolution, async pitfalls, hydration, memory limits and runtime type…
• Database 41Connections, deadlocks, constraints, replication and memory limits.
• AI 35Rate limits, context windows, GPU memory and model-serving failures.
• Network 35Refused connections, timeouts, resets, MTU problems and port exhaustion.
• Python 35Imports, virtual environments, encoding, concurrency and dependency conflicts.
• Kubernetes 34CrashLoopBackOff, ImagePullBackOff, OOMKilled, RBAC, scheduling and storage.
• Docker 27Daemon connectivity, disk space, image pulls, ports and architecture mismatches.
• System 26Disk space, systemd units, file descriptors, OOM killer and scheduled jobs.
• Cloud 25IAM permissions, quotas, service limits and credential failures.
• Security 25JWT validation, CSRF, OAuth grants, SELinux, SSH host keys and CSP.
• TLS 24Untrusted authorities, expiry, hostname mismatch, chains and cipher negotiation.

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.