← Back to Blog

Your website is down. Or your email isn't delivering. Or your API is returning timeouts. You've checked the servers, restarted the services, verified the code, and everything looks healthy. But users still can't reach you.

The problem is almost certainly DNS.

"It's always DNS" isn't just a meme in the IT community. It's an observation backed by decades of operational experience. DNS sits beneath every internet-connected service, and when it breaks, the symptoms can mimic almost any other failure: website outages, email bounces, certificate errors, API timeouts, and application crashes that leave no obvious trace in your server logs.

The challenge is that DNS failures are often silent. Your servers are running. Your application is healthy. Your monitoring dashboard shows green across the board. But somewhere in the DNS resolution chain, something is wrong, and the only way to find it is to know where to look.

This guide walks through the most common DNS problems, how to identify them, and how to fix them.

Step 1: Confirm It's Actually a DNS Problem

Before diving into DNS troubleshooting, rule out the obvious. A DNS problem means the domain name isn't resolving to the correct IP address (or isn't resolving at all). If the domain resolves correctly but the server isn't responding, that's a server or network problem, not a DNS problem.

The fastest way to check: use the DNS lookup tool at dnsassistant.com/tools. Enter your domain and query the A record. If the tool returns the correct IP address, DNS is working and the problem is elsewhere (server, firewall, CDN, application). If it returns the wrong IP, no result, or an error, you have a DNS issue.

You can also check from your local machine. Try accessing the site by IP address directly (if you know it). If the site loads by IP but not by domain name, that confirms DNS is the problem.

The Most Common DNS Problems

Problem: Domain Not Resolving at All (NXDOMAIN)

An NXDOMAIN response means the domain doesn't exist in DNS. The resolver asked the authoritative nameserver and was told there's no record for that name.

Common causes:

  • Domain expired. If you didn't renew your domain registration, the registrar removes the nameserver delegation and the domain stops resolving. Check your domain's WHOIS data using the DNS Assistant tools page to see the expiration date and registration status.
  • Typo in the domain name. This sounds obvious, but it's surprisingly common, especially in configuration files, CNAME targets, and API URLs. A missing dot, an extra hyphen, or a swapped letter can send queries to a non-existent domain.
  • Subdomain record doesn't exist. You're trying to access api.yourcompany.com but the A record or CNAME for api was never created. The parent domain resolves fine, but the subdomain returns NXDOMAIN.
  • Nameserver delegation removed. The registrar's nameserver records no longer point to your DNS provider. This can happen if you switch DNS providers but don't update the registrar, or if the registrar resets the delegation due to a billing issue.

How to fix: First, verify the domain registration is active and the nameserver delegation is correct. Then check that the specific record exists on your DNS provider. If you just created the record and it's not resolving yet, you may be hitting negative caching — resolvers cache "not found" responses too. Wait for the negative cache TTL to expire (defined in your SOA record's minimum TTL field, typically 5-60 minutes).

Problem: Domain Resolves to the Wrong IP

The domain resolves, but to an old or incorrect IP address. The website loads a different site, or the connection times out because the IP belongs to infrastructure you no longer use.

Common causes:

  • Stale A record after a server migration. You moved to a new server but forgot to update the DNS record. Or you updated it, but it hasn't propagated yet.
  • DNS propagation in progress. You recently changed the record and some resolvers still have the old value cached. This is normal and resolves on its own when the TTL expires.
  • Unauthorized change. Someone modified the DNS record without authorization, either through a compromised DNS provider account, a registrar-level attack, or an internal misconfiguration.
  • CNAME pointing to a changed target. Your domain has a CNAME pointing to a third-party service, and that service changed their IP addresses. Your DNS record is technically correct (the CNAME hasn't changed), but the ultimate resolution target has shifted.

How to fix: Use the DNS lookup tool to check what the current resolution returns. If it shows the old IP, check the TTL to estimate when propagation will complete. If the record on your DNS provider shows the correct new IP but resolvers are returning the old one, it's a propagation delay. If the record on your provider is also wrong, someone changed it.

Prevention: DNS Assistant monitors all A and AAAA records and alerts you when IP addresses change, whether the change was planned or not.

Problem: SERVFAIL Responses

SERVFAIL means the resolver tried to look up your domain but encountered an error during the resolution process. Unlike NXDOMAIN (which is a definitive "doesn't exist"), SERVFAIL means something went wrong along the way.

Common causes:

  • Lame delegation. Your registrar's NS records point to nameservers that don't actually serve your zone. The resolver queries the nameserver, but it responds with "I don't know about that domain." This is one of the most common DNS misconfigurations.
  • DNSSEC validation failure. If your domain uses DNSSEC and the signatures are invalid, expired, or the chain of trust is broken, validating resolvers will return SERVFAIL. This affects resolvers like Google (8.8.8.8) and Cloudflare (1.1.1.1) but not non-validating resolvers, which is why some users can reach the site and others can't.
  • Nameserver outage. Your authoritative nameservers are down or unreachable. If all listed nameservers are unavailable, resolvers return SERVFAIL.
  • Firewall blocking DNS. A firewall between the resolver and your nameserver is blocking DNS queries (port 53 UDP/TCP).

How to fix: Check that your nameservers are responding. Verify the NS delegation matches at both the registrar level and in your zone. If you use DNSSEC, verify the chain of trust is intact. Run a Free Domain Risk Report to get a comprehensive view of your DNS configuration including DNSSEC validation status.

Problem: Email Not Delivering

Email delivery failures are among the most common DNS-related issues, and among the hardest to diagnose because the symptoms are delayed (bounces arrive minutes to hours later) and the error messages are often cryptic.

Common causes:

  • Missing or incorrect MX records. If your domain has no MX records, or MX records that point to a non-existent or non-responsive mail server, incoming email bounces. Use the DNS lookup tool to query your MX records and verify they point to working mail servers.
  • SPF failure. Your sending server's IP isn't listed in your SPF record. The receiving server checks and sees the IP isn't authorized, marking the email as suspicious or rejecting it outright. Common after adding a new email service without updating SPF.
  • SPF exceeding the 10-lookup limit. Too many include mechanisms in your SPF record pushes the DNS lookup count over 10, causing a permanent error. Many receivers treat this as a fail. This is the single most common SPF misconfiguration.
  • DKIM signature failure. The DKIM public key in DNS doesn't match the private key used to sign the message, or the DKIM selector record is missing. This happens during key rotations, when DNS records are updated before or after the signing infrastructure switches keys.
  • DMARC policy blocking. Your DMARC policy is set to p=reject or p=quarantine, and the sending service fails both SPF and DKIM alignment. Forwarded email is especially prone to this, since forwarding changes the sending IP (breaking SPF) and may modify headers (breaking DKIM).
  • Missing PTR record. The sending server's IP address doesn't have a reverse DNS (PTR) record. Many receiving servers, including Gmail, reject or deprioritize email from IPs without valid PTR records.

How to fix: Start by running a Free Domain Risk Report which checks MX, SPF, DKIM, and DMARC configuration in a single scan. The report flags missing records, policy weaknesses, and misconfigurations. For ongoing protection, DNS Assistant monitors all email-related records and alerts when changes occur.

Problem: SSL/TLS Certificate Errors

Users see "Your connection is not private" or "NET::ERR_CERT_COMMON_NAME_INVALID" errors. The site loads but the browser flags the certificate as invalid.

DNS-related causes:

  • DNS pointing to the wrong server. The domain resolves to a server that has a certificate for a different domain. This often happens after migrations when DNS is updated but the new server's certificate hasn't been provisioned yet.
  • CNAME to a service with certificate mismatch. Your subdomain CNAMEs to a SaaS provider, but the provider's certificate doesn't include your custom domain. You need to configure the custom domain in the provider's dashboard so they provision a certificate.
  • CAA record blocking issuance. Your CAA records restrict certificate issuance to specific CAs, but the CA trying to issue (e.g., Let's Encrypt during an auto-renewal) isn't in the allowed list.
  • DNS-01 challenge failure. Let's Encrypt and other CAs use DNS TXT records for domain validation. If the validation TXT record isn't created or hasn't propagated, certificate issuance fails.

How to fix: Use the DNS lookup tool to verify your A record points to the correct server. Check your CAA records to ensure the correct CA is authorized. If using DNS validation for certificate issuance, verify the TXT record exists and has propagated.

Problem: Intermittent Resolution Failures

The domain works sometimes but fails other times. Some users can reach it, others can't. The issue comes and goes without any pattern.

Common causes:

  • One of multiple nameservers is down. If you have three nameservers and one is unresponsive, resolvers that happen to query that nameserver get failures while others succeed. Use the DNS lookup tool to query each nameserver individually.
  • DNS round-robin with a dead server. Multiple A records exist for load balancing, but one of the IPs points to a dead server. Users randomly get the dead IP.
  • TTL expiration timing. During propagation, some resolvers have the new record and some have the old one. This creates intermittent behavior that resolves over time as caches expire.
  • Network-specific issues. Some ISP resolvers may be having issues, or specific network paths to your nameservers may be degraded. Users on different ISPs see different behavior.
  • DNSSEC partial failure. DNSSEC-validating resolvers return SERVFAIL while non-validating resolvers work fine. Since different users use different resolvers, the failure appears intermittent.

How to fix: Test resolution against multiple resolvers to identify if the failure is resolver-specific. Check all your nameservers individually to find the unresponsive one. If the pattern maps to "some users fail, others don't" consistently, DNSSEC validation failure is a strong suspect.

A Systematic Troubleshooting Approach

When DNS breaks, work through these checks in order:

  1. Is the domain registered and active? Check WHOIS data for expiration date and status. A domain that's expired, suspended, or in redemption won't resolve.
  2. Are the nameservers correct? Verify that the NS records at the registrar match the nameservers at your DNS provider. Lame delegation (registrar points to nameservers that don't serve your zone) is one of the most common issues.
  3. Does the record exist? Query the specific record type you need (A, MX, TXT, etc.) using the DNS lookup tool. If the record doesn't exist, create it.
  4. Is the record correct? The record exists but contains the wrong value. Check for typos in IP addresses, hostnames, and TXT record content.
  5. Is it a propagation issue? If you just made a change, check the TTL on the old cached record. If the TTL is still counting down, wait for it to expire.
  6. Is DNSSEC the problem? If your domain uses DNSSEC, run a Domain Risk Report to validate the chain of trust. DNSSEC failures cause SERVFAIL on validating resolvers only, creating symptoms that look intermittent.
  7. Is the problem local or global? If you're the only one experiencing the issue, it may be your local DNS cache, VPN, or hosts file. Clear your local cache and test again.

Clearing Local DNS Caches

If DNS changes aren't showing up on your machine but are visible in the DNS lookup tool, your local cache is serving a stale record.

Browser cache: Browsers maintain their own DNS cache. In Chrome, navigate to chrome://net-internals/#dns and click "Clear host cache." Or simply restart the browser.

Windows: Open Command Prompt as Administrator and run ipconfig /flushdns

macOS: Open Terminal and run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd-resolved): Run sudo resolvectl flush-caches

After flushing, verify resolution again. If the DNS lookup tool shows the correct answer but your machine still doesn't, check for a local hosts file entry (/etc/hosts on Linux/macOS, C:\Windows\System32\drivers\etc\hosts on Windows) or a VPN that's overriding DNS.

When It's Not DNS (But Looks Like It)

Some problems mimic DNS failures but have different root causes:

  • CDN cache serving old content. DNS is correct, but the CDN is caching the old origin. Purge the CDN cache, not the DNS cache.
  • Firewall blocking traffic. DNS resolves correctly, but a firewall is blocking HTTP/HTTPS traffic to the IP. The browser shows a timeout that looks like a DNS failure.
  • Server not listening on the right port. The IP is correct, but the web server isn't configured to serve your domain (missing virtual host configuration).
  • Certificate for the wrong domain. DNS is fine, but the TLS certificate on the server doesn't match the requested hostname. The browser blocks the connection with a certificate error.
  • Application-level DNS caching. Some applications, especially Java-based ones, cache DNS lookups aggressively. The system DNS has updated, but the application is still using a cached IP from its own resolver.

Prevention: Monitor Before It Breaks

The best DNS troubleshooting is the troubleshooting you never have to do. Most DNS problems are preventable with proactive monitoring.

DNS Assistant continuously monitors your DNS records across all record types and alerts you when something changes. Whether it's an expired domain, a lame nameserver delegation, a modified MX record, a broken DNSSEC chain, or an unauthorized A record change, your team knows about it before users start complaining.

  • Record change detection: Every record type monitored, with alerts on any change
  • WHOIS monitoring: Domain expiration warnings and registration change alerts
  • Email authentication tracking: SPF, DKIM, and DMARC changes flagged immediately
  • Dangling DNS detection: Identifies abandoned records pointing to decommissioned cloud services
  • Multi-channel alerts: Email, Slack, Microsoft Teams, webhooks, and SMS

Start with a free scan: Run a Free Domain Risk Report to get a comprehensive view of your DNS health, or use the DNS lookup tool to check specific records instantly.

For continuous monitoring and proactive alerting, sign up at dnsassistant.com.

Start Monitoring Your DNS Today

Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.

Sign Up Free