Common DNS issues and how to diagnose them

DNS problems can make a healthy website look broken. A server may be running, an application may be deployed, and certificates may be valid, but users still fail to reach the service because names do not resolve to the right place. DNS also affects email delivery, certificate issuance, CDN routing, load balancing, and domain ownership workflows. Small mistakes can create broad symptoms.

The hardest part of DNS troubleshooting is that different observers may see different answers at the same time. Recursive resolvers cache records. Authoritative servers may update at different moments. Some users query corporate DNS, some use ISP resolvers, and some use public resolvers. A change that looks fixed from one laptop may still be stale elsewhere.

Good diagnosis starts by separating the type of failure: no answer, wrong answer, stale answer, intermittent answer, or correct DNS with a problem somewhere after resolution.

No answer or NXDOMAIN

An NXDOMAIN response means the queried name does not exist from the resolver's point of view. This can happen because the record was never created, the wrong hostname is being queried, a zone was removed, a registrar delegation is wrong, or a DNS provider has not loaded the zone correctly.

Start by checking the exact name, including subdomains. www.example.com and example.com are different names. So are api.example.com and api.prod.example.com. Many incidents come from editing one name while users or certificates depend on another.

Then check delegation. The registrar tells the world which nameservers are authoritative for the domain. If the registrar points to old nameservers, editing records in the new DNS provider will not help. If the authoritative nameservers disagree with each other, users may see inconsistent results depending on which server answers.

Wrong IP address or stale records

A record can exist but point to the wrong destination. This often happens during migrations, CDN onboarding, origin moves, disaster recovery tests, or rollback attempts. Stale records are especially common when teams forget about time to live values. A low TTL before a planned migration can reduce caching pain. A high TTL left in place can make a mistake linger.

Do not assume a resolver is wrong just because it returns an old answer. It may be honoring a valid cache. Compare the answer from authoritative nameservers with answers from several recursive resolvers. If authoritative DNS is correct but recursive resolvers are stale, time may be the main factor. If authoritative DNS is wrong, fix the zone first.

Also check for hidden dependencies. A CNAME may point to another name that is wrong. An apex record may be handled through ALIAS, ANAME, flattening, SVCB, or HTTPS behavior depending on the provider. A load balancer name may resolve differently by region. Follow the chain until you reach the actual service endpoint.

CNAME and apex confusion

CNAME records are useful aliases, but they have rules. A name with a CNAME generally should not have other record types at the same name. The zone apex, such as example.com, needs records like SOA and NS, so traditional CNAME use at the apex is not allowed. Many DNS providers offer alternatives, but the behavior and terminology vary.

This causes practical mistakes. A team may configure www correctly but leave the apex broken. Another team may point the apex through a provider-specific alias and then forget that it behaves differently from a normal A record. During provider changes, these special records may not export cleanly.

Before changing apex routing, document the current record type, provider behavior, target, TTL, and rollback plan. Test both the apex and www names because users, certificates, redirects, and search results may use either.

Email records that almost work

DNS issues are not limited to websites. MX, SPF, DKIM, and DMARC records influence email delivery and spoofing protection. A domain can send mail successfully in some cases while still failing authentication checks elsewhere.

Common problems include missing MX records, SPF records that exceed lookup limits, multiple SPF records at the same name, DKIM selectors published in the wrong place, and DMARC policies that are stricter than the sending setup can support. These issues often appear as intermittent delivery failures, spam-folder placement, or authentication warnings in receiving systems.

Email DNS changes should be tested with real sending paths, including marketing tools, helpdesk systems, billing systems, and application mail. It is easy to fix corporate email while breaking a third-party sender that uses the same domain.

DNSSEC and validation failures

DNSSEC adds cryptographic validation to DNS, but misconfiguration can make a valid domain appear broken to validating resolvers. Problems often involve DS records at the registrar, key rollovers, expired signatures, or a mismatch between the registrar and DNS provider.

If only some users cannot resolve a domain and validating public resolvers fail while non-validating tests pass, DNSSEC should be considered. During provider migrations, confirm whether DNSSEC is enabled, whether DS records need to be removed or updated, and who owns key management. DNSSEC is valuable, but it needs careful operational handling.

Intermittent and regional issues

Intermittent DNS failures can come from inconsistent authoritative nameservers, anycast routing problems, resolver-specific cache state, split-horizon DNS, firewall rules blocking DNS responses, or provider outages. Regional differences are especially common with global DNS and CDN setups.

Collect evidence from multiple locations and resolvers. Record the resolver used, the answer, the TTL, the authoritative server, and the time of the test. Without that detail, teams can chase contradictory reports. A user in one country, a synthetic monitor in another, and an engineer on a VPN may all be telling the truth.

Practical troubleshooting workflow

Start with the user's exact symptom and hostname. Confirm whether the problem is resolution, connection, TLS, HTTP routing, or application behavior. Query authoritative nameservers directly, then compare recursive resolvers. Check registrar nameserver delegation. Follow CNAME or alias chains. Review recent DNS, registrar, CDN, certificate, and hosting changes. Look at TTLs before deciding whether a fix has had time to reach users.

For production domains, keep DNS changes small and reversible. Save the previous records before editing. Avoid making many unrelated changes during an incident. If a migration requires several records to move together, prepare a checklist and rollback plan.

Prevention

The best prevention is disciplined ownership. Maintain an inventory of important domains, zones, records, providers, renewal dates, DNSSEC status, and business owners. Use role-based access where possible. Keep change history. Monitor critical records from more than one resolver. Review TTLs before migrations, not after an outage begins.

DNS is reliable when operated deliberately, but it is unforgiving when ownership is unclear. Clear records, tested changes, and good evidence collection turn most DNS issues from mystery outages into manageable operational work.

Related learning

• What is a DNS A record?
• What is a DNS AAAA record?
• What is a DNS NS record?