When a website suddenly stops resolving or email deliveries begin to fail, one of the most effective tools to get to the root of the problem is dig (Domain Information Groper). It’s straightforward, reliable, and provides deep visibility into what’s really happening behind your domain’s DNS. In this post, we’ll explore how to use dig for DNS troubleshooting. Not just the commands, but also real-world examples that show how dig can pinpoint DNS propagation issues, record mismatches, or server misconfigurations that cause downtime or service interruptions.
What Makes dig so Useful for Troubleshooting?
The dig command lets you query DNS servers directly, displaying the exact records, TTLs, and authoritative responses involved in resolving a domain name.
Unlike browser-based DNS checkers, dig gives you full control. You can query specific servers, test different record types, and analyze responses in detail, making it the perfect tool for diagnosing what’s wrong when a domain doesn’t behave as expected.
Now that you know why dig is such a valuable tool, let’s explore how it performs in real troubleshooting situations. The following scenarios show how you can apply dig commands to diagnose and fix common DNS issues effectively.
Scenario 1 – Domain not Resolving After a DNS Change
You just switched hosting providers, updated the A record to point to the new IP address, and hours later, your website is still pointing to the old server.
Here’s where dig for DNS Troubleshooting shines. Run:
dig example.com AThis shows the IP address currently being resolved. If you still see the old IP, check what other DNS resolvers are showing:
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com
dig @9.9.9.9 example.comIf some servers show the new IP and others don’t, that confirms DNS propagation is still in progress. You can also verify the TTL to estimate how long it might take for full propagation:
;; ANSWER SECTION:
example.com. 1800 IN A 203.0.113.45Here, “1800” means 30 minutes before the cached record expires.
Scenario 2 – Emails not Sending or Receiving
Email issues are often DNS-related, usually due to misconfigured MX records. To verify mail routing, run:
dig example.com MXIf the result shows:
example.com. 3600 IN MX 10 mail.oldserver.com.but your email provider recently changed to mail.newserver.com, you’ve found the culprit.
You can also test if the mail host resolves properly:
dig mail.newserver.com AIf that returns “SERVFAIL” or “NXDOMAIN,” it means the mail server’s hostname doesn’t exist in DNS, a clear misconfiguration that needs fixing at your DNS provider.
Scenario 3 – Intermittent Resolution or “Site Not Found” Errors
If users report that your website sometimes works and sometimes doesn’t, inconsistent NS records or unsynchronized nameservers may be to blame.
Run:
dig example.com NSYou might see:
example.com. 172800 IN NS ns1.examplehost.com.
example.com. 172800 IN NS ns2.examplehost.com.Then query each nameserver individually:
dig @ns1.examplehost.com example.com A
dig @ns2.examplehost.com example.com AIf the two return different IPs, it means your DNS zone hasn’t fully synchronized between servers. That’s a classic reason for inconsistent site resolution. One user hits the correct IP while another gets directed to an outdated one.
Scenario 4 – Diagnosing Slow or Failed DNS Lookups
When a site takes unusually long to load or shows temporary “server not found” errors, latency or DNS server failures could be involved.
Use:
dig example.com +statsLook at the “Query time” line at the end:
;; Query time: 502 msecA value over 200 – 300 ms may indicate a slow DNS resolver or poor network routing. To confirm, test with another DNS server:
dig @1.1.1.1 example.com +statsIf the query is much faster with Cloudflare’s resolver, the problem might lie with your ISP’s DNS servers, not your domain configuration.
Scenario 5 – Identifying DNSSEC or Delegation Problems
Sometimes, a site that used to work suddenly stops resolving with a “SERVFAIL” message. This can happen when someone enables DNSSEC but does not configure it properly.
Check for DNSSEC details with:
dig example.com +dnssecIf you see errors like “RRSIG” missing or mismatched signatures, it means your domain’s DNSSEC keys are not aligned with your registrar’s configuration. The fix typically involves re-signing your zone or re-uploading DS records.
You can also trace the entire resolution path to identify where it breaks:
dig +trace example.comIf the trace fails mid-way, it reveals exactly which authoritative server is failing.
Scenario 6 – Subdomain or CNAME not Resolving
A common DNS issue arises when someone misconfigures a subdomain. Suppose blog.example.com isn’t loading, but the main domain works fine.
Check its record:
dig blog.example.com CNAMEYou might find:
blog.example.com. 300 IN CNAME example.com.If the parent domain (example.com) doesn’t have an A record, that explains why the subdomain also fails. A missing A record in the chain breaks the resolution.
Helpful dig options for faster diagnostics
+short – show only essential information
dig example.com A +short+noall +answer – display just the answer section
dig example.com MX +noall +answer+trace – trace DNS delegation
dig +trace example.com@server – query a specific DNS resolver
dig @8.8.8.8 example.comFinal thoughts
Getting comfortable with dig for DNS troubleshooting turns DNS problems from mysteries into manageable tasks. It helps you confirm if records are correctly set, test DNS propagation, diagnose mail routing issues, and uncover hidden misconfigurations before they cause downtime.
Next time a domain misbehaves, open your terminal and run a quick dig test. It might just tell you everything you need to know. Once you start using it regularly, you’ll wonder how you ever managed DNS troubleshooting without it.
