Articles

Troubleshoot DNS Issues with dig Step by Step (2026)

April 16, 2026 6 min read

dig is the Swiss Army knife for DNS troubleshooting, but it’s easy to get lost in the output if you don’t know what to look for.

Let’s say you’re trying to resolve example.com and you’re getting SERVFAIL or NXDOMAIN errors. This means your DNS resolver is failing to get a definitive answer from the authoritative DNS servers for that domain.

First, let’s check if your local resolver is even responding.

dig @1.1.1.1 example.com

If this returns a valid IP address, your local resolver is probably fine, and the issue is likely with the authoritative servers for example.com or how your network is reaching them. If it fails, then the problem is either with Cloudflare’s DNS (unlikely for a general issue) or your local machine’s ability to reach out to the internet.

Let’s assume the above worked, and we’re still seeing issues for example.com. Now we need to trace the delegation chain. We start by asking a root server for the .com servers.

dig @a.root-servers.net example.com NS

This command asks the a.root-servers.net (one of the 13 root DNS servers) for the Name Servers (NS record type) responsible for the .com top-level domain. The output will list the authoritative .com DNS servers. Look for lines like:

;; ANSWER SECTION:
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
...

Now, pick one of those .com servers (let’s use a.gtld-servers.net) and ask it for the authoritative servers for example.com.

dig @a.gtld-servers.net example.com NS

This query asks the .com TLD server for the Name Servers responsible for example.com. The answer section will show you the authoritative DNS servers for example.com itself. You’ll see something like:

;; ANSWER SECTION:
example.com.            172800  IN      NS      ns1.exampledns.com.
example.com.            172800  IN      NS      ns2.exampledns.com.

Now, we finally ask one of example.com’s authoritative servers for the actual IP address of example.com.

dig @ns1.exampledns.com example.com A

This command queries ns1.exampledns.com for the A record (IPv4 address) of example.com. If this returns an IP address, your DNS resolution is working correctly for example.com. If it fails with SERVFAIL, the authoritative server for example.com is having issues. If it returns NXDOMAIN, the domain example.com genuinely does not exist.

Common Causes & Fixes:

  1. Incorrect NS Records at the TLD Level: If the previous step (asking .com for example.com’s NS records) returned incorrect or non-existent NS servers, the delegation chain is broken.

    • Diagnosis: dig @a.gtld-servers.net example.com NS shows NS records pointing to servers that don’t exist or are misconfigured.
    • Fix: Log into your domain registrar and correct the NS records for example.com to point to the actual IP addresses of your DNS hosting provider’s name servers. For example, if your DNS provider is Cloudflare, you might update them to ns1.exampledns.com and ns2.exampledns.com if those are Cloudflare’s names for your zone.
    • Why it works: This establishes the correct path for DNS queries to find your domain’s authoritative servers.

  2. Authoritative DNS Server Not Responding or Misconfigured: If dig @ns1.exampledns.com example.com A fails, but ns1.exampledns.com is a valid hostname, the issue is with your DNS hosting.

    • Diagnosis: dig @ns1.exampledns.com example.com A results in SERVFAIL or a timeout, while dig ns1.exampledns.com A returns a valid IP address for the name server itself.
    • Fix: Contact your DNS hosting provider. They need to ensure their authoritative name servers are running, reachable, and correctly serving records for example.com. This might involve restarting their services or correcting zone file errors.
    • Why it works: This ensures the server responsible for your domain is operational and correctly configured to answer queries.

  3. Firewall Blocking DNS Traffic: A firewall on your network or the authoritative server’s network could be blocking UDP or TCP port 53.

    • Diagnosis: dig @ns1.exampledns.com example.com A times out, but ping ns1.exampledns.com works.
    • Fix: Ensure that UDP and TCP port 53 are allowed inbound and outbound on any firewalls between your client and the authoritative DNS server, and on the authoritative DNS server itself.
    • Why it works: This allows the DNS query packets to reach their destination and the responses to return.

  4. Incorrect IP Address for Authoritative Name Server (Glue Record Issue): Sometimes, the NS records at the TLD level include "glue records" – the IP addresses of the authoritative name servers. If these are wrong, the resolver can’t even find the authoritative server.

    • Diagnosis: dig @a.gtld-servers.net example.com A (asking the root for the IP of the .com server) or dig @a.gtld-servers.net example.com NS (asking .com for example.com’s NS IPs) fails to resolve the NS hostnames.
    • Fix: At your domain registrar, ensure the glue records (the IP addresses associated with ns1.exampledns.com, ns2.exampledns.com, etc.) are correctly configured and match the actual IPs of those name servers.
    • Why it works: This provides the resolver with the necessary IP addresses to directly contact the authoritative name servers for your domain.

  5. DNSSEC Validation Failures: If DNSSEC is enabled for the domain, and there’s a misconfiguration in the DNSSEC records (like incorrect signatures or validation chain issues), resolvers performing strict validation might return SERVFAIL.

    • Diagnosis: dig +dnssec @ns1.exampledns.com example.com A shows SERVFAIL or NOERROR but dig +cdflag @<your_resolver_ip> example.com A (checking with validation disabled) returns an IP. Or, dig +trace +dnssec example.com A reveals SERVFAIL at a specific delegation point.
    • Fix: This is complex. You’ll likely need to consult your DNSSEC administrator or provider. It often involves re-signing zones, ensuring correct chain of trust, or fixing misconfigured keys.
    • Why it works: It resolves signature mismatches or broken trust anchors, allowing DNSSEC-validating resolvers to trust the DNS data.

  6. Rate Limiting or IP Blocking: Authoritative DNS servers might temporarily block IPs that make too many queries, especially if they appear to be part of a DDoS attack or are misconfigured to send excessive queries.

    • Diagnosis: Repeated dig commands from the same IP to an authoritative server result in timeouts or SERVFAIL, while other IPs might succeed.
    • Fix: Wait for a period (e.g., 15-60 minutes) and try again. If the issue persists, contact the administrator of the authoritative DNS server or your DNS provider to inquire about IP blocking or rate limits.
    • Why it works: This allows your IP to be removed from any temporary blocklists and normal query rates to resume.

Once you’ve fixed the underlying issue, the next error you’ll likely encounter if you’re still having trouble is a REFUSED response, indicating that a DNS server is actively rejecting your query for policy reasons.

Want structured learning?

Take the full Dns course →