Troubleshooting & Operations••12 min read•By Silixen Engineering Team

How to Troubleshoot DNS Problems: A Beginner-Friendly Guide

When a website goes down or emails stop arriving, DNS misconfigurations are frequently the culprit. Learn how to systematically diagnose NXDOMAIN, SERVFAIL, browser probe errors, and propagation delays with safe, reliable troubleshooting techniques.

Check Your Domain with Live DNS

Run an instant DNS check across global nameservers using Silixen's free lookup utility.

Test DNS Records Now →

The 3 Layers of DNS Failure: Where Is the Problem?

Before changing nameservers or contacting tech support, it is critical to determine where the failure is occurring. DNS issues always originate in one of three distinct layers:

Layer 1: Local Device

Browser or OS Cache

The domain is live for the rest of the world, but your local operating system or Wi-Fi router has cached an old IP address or temporary resolution failure.

Layer 2: Recursive ISP

Resolver Cache & TTL

Your ISP or public recursive resolver is adhering to an unexpired TTL timer, delaying the visibility of recent DNS updates.

Layer 3: Authoritative

Zone & Registrar Config

The zone file at Cloudflare, Route 53, or your registrar has missing records, expired registrations, syntax errors, or broken DNSSEC chains.

Deciphering Common DNS Errors

1. NXDOMAIN (Non-Existent Domain)

What it means: The authoritative nameserver confirmed that the queried domain name does not exist.

Likely Causes:

  • Typo in the domain name or subdomain (e.g. ww.example.com instead of www.example.com).
  • The domain registration has expired and was suspended by the registrar.
  • The DNS zone was deleted or registrar nameservers point to inactive hosts.

2. SERVFAIL (Server Failure)

What it means: The recursive resolver was unable to obtain an answer from the domain's authoritative nameservers.

Important distinction: SERVFAIL does not mean the domain is unregistered. It means the connection between the recursive resolver and authoritative nameservers timed out, the nameservers refused traffic, or DNSSEC cryptographic validation failed.

3. Browser Errors: DNS_PROBE_FINISHED_NXDOMAIN & ERR_NAME_NOT_RESOLVED

Google Chrome and Microsoft Edge display these errors when the browser cannot find an IP address for the hostname. Before assuming your server crashed, test the domain with an independent external tool like Silixen DNS Lookup. If the external lookup succeeds with NOERROR, the problem is 100% confined to your local computer, router, or ISP.

DNS Propagation vs. DNS Caching: The Real Story

Website owners frequently hear the phrase: “Wait 24 to 48 hours for DNS to propagate.” But in modern networking, “propagation” is not a slow physical wave traveling across undersea cables. It is purely TTL expiration.

When you update an A record at your registrar or cloud provider:

  • The authoritative nameserver updates within seconds.
  • However, any resolver that looked up your domain previously holds the old record in cache until its TTL counts down to zero.
  • If your old record had a TTL of 86,400 seconds (24 hours), resolvers will not request your new IP until that full day has elapsed.

The Solution: If you plan to migrate hosting servers, lower your record TTL to 300 seconds (5 minutes) at least 48 hours before the scheduled cutover.

Step-by-Step Troubleshooting Checklist

Step 1: Flush Your Local DNS Cache

Clear stale entries stored by your operating system:

# Windows Command Prompt / PowerShell
ipconfig /flushdns
# macOS Terminal
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Step 2: Perform an External DNS Lookup

Use our Domain & DNS Lookup Tool to query Google Public DNS over HTTPS. This bypasses your local ISP and tests the authoritative state directly:

  • If A records return your new hosting IP, the configuration is working and you simply need to wait for local caches to expire.
  • If NOERROR is returned but records are empty, verify that the host name in your zone file matches your requested domain (e.g., check both root @ and www).

Step 3: Verify Nameserver Delegation at Registrar

Log into your domain registrar (GoDaddy, Namecheap, Google Domains/Squarespace, Porkbun). Ensure the nameserver fields point exclusively to your active DNS provider. Having orphaned or conflicting nameservers from two different hosts causes 50% of incoming lookups to fail randomly.

Step 4: Check DNSSEC Configuration

If you recently switched DNS providers (for example, moving from Cloudflare to AWS Route 53), make sure to remove the old DS records at your registrar. If old DNSSEC records remain active at the registrar while your new DNS provider does not sign zones, modern resolvers will return SERVFAIL and block all visitors.

Troubleshooting Email Delivery & MX Records

Email outages are almost always linked to three DNS issues:

  • Missing or Misordered MX Records: Ensure your MX records point to hostnames (e.g. smtp.google.com), never to raw IP addresses.
  • Conflicting SPF Records: Multiple SPF TXT records violate RFC 7208 and cause receiving providers (Gmail, Outlook) to mark messages as spam or reject them completely.
  • Missing PTR Record for Dedicated Mail Servers: If you operate your own mail server on VPS/dedicated hardware, ensure your hosting provider configures a matching reverse DNS (PTR) record for your sending IP address.

When to Contact Your Hosting Provider

If you have verified that your domain registration is active, your nameservers match, and your A records point to the correct IP address, but your website still fails to load, the issue is at the web server layer:

  • Use Silixen Website Uptime Checker to test HTTP response codes (like 500 Internal Server Error, 502 Bad Gateway, or 521 Web Server Is Down).
  • If the uptime checker shows a 5xx error, your server or web application crashed, but your DNS is functioning properly!