Troubleshooting Common DNS Issues: A Step-by-Step Guide

DNS issues are among the most frustrating problems you can encounter when managing a website or online service. The symptoms are often vague -- a site that refuses to load, emails that vanish into the void, or intermittent connectivity that defies explanation. The good news is that DNS problems almost always follow predictable patterns, and with the right approach, you can identify and resolve them quickly.

This guide walks you through the most common DNS issues, explains what causes them, and gives you step-by-step instructions for diagnosing and fixing each one using command-line tools like dig and nslookup, as well as browser-based tools like the DNSChkr Propagation Checker and DNS Inspector.

Website Not Loading: Is It Actually a DNS Problem?

Before diving into DNS-specific troubleshooting, you need to confirm that DNS is actually the culprit. A website can fail to load for many reasons -- server outages, firewall rules, expired SSL certificates, or application errors. DNS is only one link in the chain.

Start by running a quick DNS lookup to see if your domain resolves to an IP address at all:

dig example.com A +short

If this returns an IP address (e.g., 203.0.113.50), DNS resolution is working and your problem likely lies elsewhere -- check your web server, firewall, or application logs.

If it returns nothing or an error, you have a DNS issue. You can also verify with nslookup:

nslookup example.com

A healthy response will show the server that answered the query and the resolved IP address. An unhealthy response will show messages like ** server can't find example.com: NXDOMAIN or connection timed out; no servers could be reached.

Quick check with DNSChkr: Use the DNS Inspector to query your domain. It will show you exactly what records exist (or do not exist) for your domain, and whether the response is authoritative.

Verify the IP Address Is Correct

Even if DNS resolves, it might resolve to the wrong IP. This is common after a hosting migration. Compare the IP returned by dig against the IP your hosting provider assigned:

dig example.com A +short
# Returns: 198.51.100.25

# But your new host says the IP should be 203.0.113.50

If the IPs do not match, your DNS records need updating at your DNS provider (registrar or managed DNS service).

Diagnosing NXDOMAIN Errors and Missing Records

An NXDOMAIN (Non-Existent Domain) response means the authoritative DNS server has declared that the domain or subdomain you queried does not exist. This is different from a timeout or a SERVFAIL -- it is a definitive answer that says "this name is not in my zone."

Common causes of NXDOMAIN errors include:

• Typo in the domain name -- Check the spelling carefully. A missing letter or wrong TLD will produce NXDOMAIN.
• The DNS record was never created -- If you set up a new subdomain like app.example.com but never added the A or CNAME record, you will get NXDOMAIN.
• Domain has expired -- An expired domain will eventually stop resolving. Check your registrar account.
• Nameservers are misconfigured -- If your domain points to nameservers that do not have your zone file, all queries will return NXDOMAIN.

To diagnose, query the authoritative nameserver directly:

# First, find the authoritative nameservers
dig example.com NS +short
# Returns: ns1.dnsprovider.com. ns2.dnsprovider.com.

# Then query the authoritative server directly
dig @ns1.dnsprovider.com app.example.com A

If the authoritative server returns NXDOMAIN, the record genuinely does not exist in the zone. Log in to your DNS management panel and add it.

If the authoritative server returns the correct record but your local resolver returns NXDOMAIN, then you are dealing with a caching or propagation issue. The DNSChkr Propagation Checker will show you which global resolvers have the correct answer and which are still returning NXDOMAIN.

Fixing SERVFAIL and Server Errors

A SERVFAIL response indicates that the DNS resolver tried to look up your domain but encountered an error during the process. Unlike NXDOMAIN, SERVFAIL does not mean the domain does not exist -- it means something went wrong during resolution.

Common causes include:

• DNSSEC validation failure -- If your domain has DNSSEC enabled but the signatures are invalid, expired, or misconfigured, resolvers that validate DNSSEC will return SERVFAIL.
• Unreachable authoritative nameservers -- If all of your nameservers are down or unreachable, resolvers cannot complete the lookup.
• Broken delegation -- If your registrar points to nameservers that do not serve your zone, the chain of delegation is broken.
• Zone file syntax errors -- A malformed zone file on the authoritative server can cause it to fail to load the zone entirely.

To check if DNSSEC is the problem, compare responses with and without DNSSEC validation:

# With DNSSEC validation (default for most resolvers)
dig example.com A @8.8.8.8

# Without DNSSEC validation using the +cd (checking disabled) flag
dig example.com A @8.8.8.8 +cd

If the +cd query succeeds but the normal query returns SERVFAIL, you have a DNSSEC issue. Check your DNSSEC configuration -- DS records at the registrar, DNSKEY records in your zone, and signature expiration dates.

To check nameserver reachability:

# Query each authoritative nameserver individually
dig @ns1.dnsprovider.com example.com A +tcp +timeout=5
dig @ns2.dnsprovider.com example.com A +tcp +timeout=5

If one or more nameservers fail to respond, contact your DNS provider.

Resolving Slow DNS Resolution and High Latency

Slow DNS resolution manifests as websites that take several seconds to start loading, even though the site itself is fast once connected. Users often describe this as "the page just sits there for a while before anything happens."

Measuring DNS Resolution Time

You can measure how long DNS resolution takes with dig:

dig example.com A | grep "Query time"
# ;; Query time: 245 msec

A healthy DNS query should resolve in under 100 milliseconds. Anything over 200ms will be noticeable to users. Anything over 1000ms indicates a serious problem.

Common Causes of Slow DNS

1. Distant or overloaded nameservers -- If your authoritative nameservers are hosted in a single geographic region far from your users, resolution will be slow. Consider using a DNS provider with global anycast infrastructure.

2. Too many CNAME chains -- Each CNAME record requires an additional lookup. A chain like www -> lb -> cdn -> origin adds latency at each step:

www.example.com.    CNAME  lb.example.com.
lb.example.com.     CNAME  cdn.provider.net.
cdn.provider.net.   A      203.0.113.50

Flatten CNAME chains where possible. Many DNS providers support CNAME flattening or ALIAS records at the zone apex.

3. Low or missing TTL values -- Extremely low TTL values (e.g., 30 seconds) force resolvers to re-query your authoritative servers frequently. Unless you need rapid failover, a TTL of 300 to 3600 seconds is a good balance.

4. Resolver issues -- Your ISP's DNS resolver might be slow. Try switching to a public resolver like Google (8.8.8.8), Cloudflare (1.1.1.1), or Quad9 (9.9.9.9) and compare performance.

Use the DNSChkr Propagation Checker to see response times from DNS servers around the world. This helps you identify whether slow resolution is a global issue or limited to specific regions.

Stale Records: Why Your Site Still Shows the Old Host

One of the most common complaints after a hosting migration is: "I updated my DNS records hours ago, but the site still shows the old host." This is almost always caused by DNS caching.

Understanding the Caching Chain

DNS responses are cached at multiple levels:

1. Browser cache -- Chrome, Firefox, and other browsers maintain their own DNS cache, typically for 60 seconds.
2. Operating system cache -- Your OS caches DNS responses. On most systems, entries persist for the duration of the TTL.
3. Router cache -- Some home and office routers cache DNS responses.
4. Recursive resolver cache -- Your ISP's DNS resolver (or a public resolver like 8.8.8.8) caches responses for the duration of the TTL.

Clearing Caches Step by Step

Start from the closest cache and work outward:

Browser: Close and reopen the browser, or navigate to the internal DNS cache page:

• Chrome: chrome://net-internals/#dns and click "Clear host cache"
• Firefox: Type about:networking#dns and click "Clear DNS Cache"

Operating system:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

Recursive resolver: You cannot flush your ISP's cache directly. You either need to wait for the TTL to expire or temporarily switch to a different resolver.

Check Global Propagation Status

The fastest way to see whether the old or new IP is being served worldwide is to use the DNSChkr Propagation Checker. It queries dozens of DNS servers across multiple continents and shows you exactly which servers have the old record and which have the new one. This tells you whether the issue is local to your machine or a broader propagation delay.

Using DNSChkr Tools for Systematic DNS Diagnosis

When troubleshooting DNS issues, having the right tools makes the difference between guessing and knowing. DNSChkr provides two key tools that complement command-line utilities:

DNS Inspector

The DNS Inspector lets you query any domain for any record type -- A, AAAA, CNAME, MX, TXT, NS, SOA, and more. It is particularly useful for:

• Verifying that records exist and contain the expected values
• Checking MX records when email is not working
• Inspecting TXT records for SPF, DKIM, and DMARC configuration
• Viewing SOA records to check serial numbers and TTL values

Propagation Checker

The Propagation Checker queries your domain from DNS servers distributed around the world. Use it to:

• Confirm whether a DNS change has propagated globally or is still in progress
• Identify geographic regions where old cached records persist
• Verify that all authoritative nameservers are returning consistent results
• Monitor the progress of a migration in real time

Together with dig and nslookup on your local machine, these tools give you complete visibility into every layer of the DNS resolution chain.

When to Contact Your Registrar vs. Your Hosting Provider

One of the trickiest parts of DNS troubleshooting is knowing who to contact when something goes wrong. The answer depends on where the problem lies in the DNS chain.

Contact your registrar when:

• Your domain has expired or is in redemption period
• The nameserver delegation (NS records at the registry level) is incorrect
• DNSSEC DS records at the registry level need updating
• WHOIS information shows incorrect nameservers
• You need to unlock your domain for a transfer

Contact your hosting or DNS provider when:

• Individual DNS records (A, CNAME, MX, TXT) are missing or incorrect
• Your zone file has errors
• Nameservers are not responding to queries
• DNSSEC keys within your zone need rotation
• You are experiencing high latency or timeouts from their nameservers

To determine which applies to your situation, check the delegation chain:

# Check which nameservers the registry has on file
dig example.com NS +trace

If the NS records returned by the parent zone (e.g., .com) are wrong, that is a registrar issue. If the NS records are correct but the authoritative nameservers are returning wrong data, that is a DNS provider issue.

Key Takeaways

• Confirm DNS is the problem first -- Run dig or nslookup before assuming DNS is the cause of a site not loading. If the domain resolves to the correct IP, the issue is elsewhere.
• Learn to read error responses -- NXDOMAIN means the record does not exist; SERVFAIL means something went wrong during resolution. Each requires a different fix.
• Check the authoritative source -- Always query your authoritative nameservers directly to distinguish between a genuine missing record and a caching or propagation delay.
• Flush caches methodically -- Clear your browser cache, OS cache, and consider switching resolvers before concluding that DNS has not updated.
• Use global checking tools -- The DNSChkr Propagation Checker shows you whether a DNS change has reached resolvers worldwide, eliminating guesswork.
• Know your escalation path -- Registrar issues (delegation, expiration, WHOIS) are different from DNS provider issues (record values, zone errors, nameserver performance). Identify where the break is before contacting support.
• Keep TTL values sensible -- Excessively low TTLs cause slow resolution; excessively high TTLs make changes slow to propagate. A range of 300 to 3600 seconds works well for most use cases.

Having DNS trouble right now? Run your domain through the DNSChkr Propagation Checker to see how your records look from servers around the world, or use the DNS Inspector to examine your records in detail.