DNS Troubleshooting — Step-by-Step Diagnosis

The Methodical Approach to DNS Troubleshooting

DNS problems can appear as "site won't open", "email not sending", "SSL error after changing nameservers" or "subdomain not working". The common denominator: somewhere in the DNS chain something doesn't match.

The correct approach is top-down — start from the root nameservers and work down:

1. Root / TLD nameservers → do they know about the domain?
2. Authoritative nameservers → do they have the correct records?
3. Resolvers (Cloudflare, Google) → what do they return?
4. Local resolver (your ISP) → what cache does it hold?

Check 1 — Delegation: Do TLD Nameservers Know About the Domain?

Before doing anything else, confirm the delegation is correct. Query the TLD nameserver directly:

dig NS example.com @a.gtld-servers.net    # for .com domains
dig NS example.co.uk @ns1.nic.uk          # for .uk domains

If no nameservers are returned for your domain, the problem is at the registry — contact your registrar.

Check 2 — Authoritative Nameservers: Do They Have the Right Records?

Query your domain's authoritative nameserver directly (bypass cache):

dig A example.com @ns1.example.com
dig MX example.com @ns1.example.com
dig TXT example.com @ns1.example.com

If the authoritative returns correct values but public resolvers don't see them, it's a caching issue — simply wait for the TTL to expire.

If the authoritative itself has wrong values, the problem is in the DNS zone — go to your DNS management panel and fix it.

Check 3 — SOA Record: The Right Authoritative?

dig SOA example.com

The SOA (Start of Authority) record shows who the primary nameserver is. If it differs from who you think you're using, you've been making changes at the wrong provider.

Check 4 — MX Records: Are Emails Arriving?

If emails aren't arriving:

dig MX example.com               # Does MX record exist?
dig A mail.example.com           # Does MX hostname resolve?
dig -x 203.0.113.10              # Does PTR (reverse DNS) exist?
telnet mail.example.com 25       # Is the server listening?

Common MX problems:

• Missing trailing dot on MX hostname (mail.example.com instead of mail.example.com.) — in some DNS panels this causes errors
• MX hostname doesn't resolve to an IP (missing A record)
• Wrong priority — lower number = higher priority

Check 5 — TTL and Propagation

Check the TTL of the records you changed:

dig A example.com | grep -i ttl

If the TTL was high (e.g. 86400 = 24 hours) at the time of the change, some resolvers may hold the old value for hours. Check from multiple resolvers simultaneously to determine whether propagation is complete.

Check 6 — DNSSEC: If Used

If the domain uses DNSSEC and something goes wrong, resolvers that support DNSSEC (Cloudflare, Quad9) will return SERVFAIL instead of the record. Check:

dig A example.com @1.1.1.1 +dnssec    # Cloudflare with DNSSEC
dig A example.com @8.8.8.8 +dnssec    # Google with DNSSEC

If you get SERVFAIL with DNSSEC but NOERROR without, you have a DNSSEC misconfiguration — usually an expired or incorrect DS record at the registry.

Quick Troubleshooting Checklist