Troubleshooting DNS misconfiguration

Why Does DNS Troubleshooting Seem Complicated?

When your website is down, the first thing that comes to mind is that the server has a problem. But in many cases, the root of the problem lies elsewhere: in DNS settings. DNS acts like the internet's phone book; if this phone book has incorrect information, users won't reach their destination no matter how correct the address they enter is.

The issue is that DNS errors don't always look the same. Sometimes the site doesn't load at all, sometimes only emails don't work, and sometimes the site loads for some users but not others. In this article, you'll learn a systematic method for DNS troubleshooting: first, you'll recognize the symptoms of each error, then you'll check records in the correct order to get to the root cause.

Common Symptoms of DNS Errors and What Each One Means

Before we get to the commands, you need to know what type of error each symptom points to. Build this mental table:

1. "DNS_PROBE_FINISHED_NXDOMAIN" Error

This error means your domain doesn't exist at all or no records are registered for it. The browser is saying: "I couldn't find this address on any DNS server."

• Possible cause: The domain has expired, DNS records have been completely deleted, or the domain hasn't been activated yet.
• Note: If you've just purchased the domain, DNS propagation may not be complete yet.

2. "DNS_PROBE_FINISHED_SERVFAIL" Error

This error means your domain's DNS server is responding, but it can't return correct information. The problem is usually on the side of the Name Servers.

• Possible cause: Incorrect settings on the DNS server, corrupted SOA record, or a problem with the domain's authoritative servers.
• Note: This error is often temporary; but if it recurs, you should check the name server settings.

3. Site Loads for Some Users but Not Others

This is the classic sign of incomplete DNS propagation. When you change a record, DNS servers around the world keep the old information in their cache. Some users connect to servers that have received the new information, while others connect to old servers.

• Possible cause: Recent changes to records, TTL (Time To Live) set too high.
• Note: If you set the TTL to a low value (e.g., 300 seconds) before making changes, propagation will be faster.

4. Website Loads but Email Doesn't Work

This problem is usually related to MX and SPF records. Your site might be on the correct host, but if the MX record points to the wrong email server, emails won't reach their destination.

• Possible cause: Incorrect MX record, incomplete SPF record, or no A record set for mail.example.com.
• Note: Emails usually don't show a clear error to the user; emails just get lost or go to spam.

The Correct Order for Checking Records in DNS Troubleshooting

Now that you know the symptoms, it's time to check systematically. Follow this order to get to the root cause:

Step One: Check A and AAAA Records

The A record (and AAAA for IPv6) are the most important records. If these are wrong, nothing else will work correctly. Use the dig command:

dig example.com A
dig example.com AAAA

The output should include a valid IP address. If the ANSWER SECTION is empty, it means the record doesn't exist. If you see the IP address but the site doesn't load, the problem isn't DNS; it's the web server.

Step Two: Check NS and SOA Records

NS (Name Server) records determine which servers are authoritative for your domain. If these are wrong, the entire domain goes down. Check:

dig example.com NS
dig example.com SOA

In the NS output, you should see at least two name servers. In the SOA output, pay attention to the MNAME field (primary server) and the REFRESH and RETRY fields. Unusual values (like REFRESH less than 3600) can cause instability.

Also, make sure the NS records are consistent in two places: at the domain registrar (where you bought the domain) and in your own DNS zone. If these two differ, strange problems will arise.

Step Three: Check MX and SPF Records

If the site is up but email isn't working, do this step:

dig example.com MX
dig example.com TXT

The MX record should point to a valid hostname (e.g., mail.example.com) and have a priority number between 0 and 65535. The SPF record should be in the TXT section and start with v=spf1. Example:

v=spf1 mx include:_spf.google.com ~all

If SPF is missing or incorrect, your emails may go to spam or be rejected entirely.

Step Four: Check CNAME Records and Special Records

CNAME records are used for subdomains (like www or blog). Check:

dig www.example.com CNAME
dig blog.example.com CNAME

A common mistake is setting a CNAME record for the root domain (like example.com). This is not allowed per RFC standards; the root domain must have an A record. If you've made this mistake, remove the CNAME record and set an A record instead.

Step Five: Check Local and Public DNS Cache

Sometimes the problem is on your end, not the server. Clear your system's DNS cache:

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

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

# On Windows
ipconfig /flushdns

After clearing the cache, check again. If the problem is resolved, the local cache was corrupted. If not, use a public DNS like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare):

dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A

If you get the correct answer with public DNS but not with your ISP's default DNS, the problem is with your ISP's DNS server.

Helpful Tools for DNS Troubleshooting

In addition to command-line tools, online tools can also help:

• dnschecker.org: Check DNS propagation worldwide.
• whatsmydns.net: View record status from different locations.
• Google Admin Toolbox: Google's comprehensive tool for DNS checking.

These tools show you whether the problem is only in your region or worldwide. If you see errors everywhere, the problem is with your settings; if it's only in one region, the problem is with that region's infrastructure.

Practical Scenario: A Complete Troubleshooting Example

Suppose a user reports that the site shop.example.com isn't loading. We'll follow these steps in order:

1. Check the A record: dig shop.example.com A — The output shows the IP address. So DNS is working.
2. Check connection to the server: curl -I http://shop.example.com — We get a timeout error. The problem is with the server, not DNS.
3. Check the port: nc -zv shop.example.com 80 — The port is closed. The firewall or web server has a problem.
4. Conclusion: DNS is correct; the problem is with the server infrastructure. This time savings demonstrates the value of systematic troubleshooting.

Summary: DNS Troubleshooting Roadmap

To always follow the right path, keep this checklist in mind:

• First, check the A and AAAA records; if they're correct, the problem is elsewhere.
• Check NS and SOA records; if they're wrong, the entire domain goes down.
• For email issues, check MX and SPF.
• Try local cache and public DNS to make sure the problem isn't on your end.
• Use online tools to check global propagation.

With this method, you won't be guessing anymore. Each symptom points to a category of errors, and each category has a specific check order. If during troubleshooting you conclude that your DNS infrastructure needs a fundamental review, you can use ServerNet's managed DNS services to have the settings professionally reviewed. But in most cases, this simple guide is enough to find and fix the problem.