Troubleshoot DNS Lookups by Reading dig Responses

Yes, you can troubleshoot DNS lookups by reading dig responses, and the key is learning to interpret the ANSWER, AUTHORITY, and ADDITIONAL sections along with the status flags. Dig (Domain Information Groper) is a command-line tool that queries DNS servers and prints the raw response, giving you more detail than nslookup or host. This article explains how to read every part of a dig output, what common errors mean, and how to use flags to isolate problems.

What dig Actually Shows You

When you run dig example.com, the output is divided into five main blocks: the header, the QUESTION section, the ANSWER section, the AUTHORITY section, and the ADDITIONAL section. The header contains the opcode (QUERY), the status (NOERROR, NXDOMAIN, SERVFAIL, etc.), and flags like qr (query response), rd (recursion desired), and ra (recursion available). The QUESTION section repeats what you asked for — the name, type (A, AAAA, MX, etc.), and class (IN for internet). The ANSWER section is the actual DNS record(s) returned. The AUTHORITY section lists the authoritative name servers for the domain, and the ADDITIONAL section contains extra records, like the IP addresses of those name servers.

Understanding the Status Field

1. NOERROR — The query was successful, and the answer may be in the ANSWER section. If the ANSWER section is empty, it means the name exists but the record type you asked for does not (e.g., an A record exists but no MX).
2. NXDOMAIN — The domain name does not exist. This is a definitive “not found” answer from the authoritative server. If you get NXDOMAIN but the site works in a browser, you likely have a DNS caching issue or are querying the wrong server.
3. SERVFAIL — The DNS server could not reach the authoritative server or encountered a timeout. This often points to a network problem, a misconfigured forwarder, or an overloaded upstream server.
4. REFUSED — The server refused to answer, usually because it is not authoritative for the zone and recursion is disabled, or the query type is blocked.

Reading the ANSWER Section

Each line in the ANSWER section has five fields: name, TTL, class, type, and data. For example:

example.com. 3600 IN A 93.184.216.34

The TTL (time to live) is the number of seconds the record can be cached. A TTL of 3600 means one hour. The type tells you the record kind: A (IPv4 address), AAAA (IPv6), MX (mail exchange), NS (name server), CNAME (canonical name), TXT (text), etc. The data is the value — for an A record, it’s the IP address. If you see multiple lines, the server returned multiple records, which is normal for round-robin load balancing.

Using dig Flags to Diagnose Specific Problems

• dig +short — Prints only the data field, useful for quick checks.
• dig +trace — Follows the query from root servers down to the authoritative server, showing each step. This is invaluable for finding where a resolution chain breaks.
• dig @8.8.8.8 example.com — Queries a specific DNS server (here, Google’s public resolver) instead of your system default. This helps determine if the problem is with your local resolver or the authoritative server.
• dig example.com ANY — Returns all record types (though many servers restrict ANY queries).
• dig example.com MX — Queries a specific record type like mail exchange.
• dig +norecurse — Asks the server not to perform recursion, so you can see if the server has the answer cached or is authoritative.

Common dig Output Patterns and Their Meanings

If you see a response with status: NOERROR but an empty ANSWER section, the record type you asked for doesn’t exist. For example, dig example.com MX might return NOERROR with no answer if the domain has no mail servers. If you see status: NXDOMAIN in the ANSWER section, the domain itself is not registered. If you see flags: aa (authoritative answer), the response came directly from the authoritative server — this is what you want when testing a zone transfer or delegation. If you see flags: ra but not aa, the answer came from a recursive resolver, which is normal for most lookups but means the answer could be cached.

Comparing dig with nslookup and host

nslookup and host are simpler but less detailed. nslookup shows the same basic sections but omits the header flags and TTLs by default. host gives a concise one-line answer. dig is the preferred tool for troubleshooting because it shows the raw response, including the EDNS (extension mechanisms for DNS) section, which is crucial for diagnosing DNSSEC or large UDP response issues. For example, if you suspect a DNS response is being truncated, dig will show truncated in the flags, which nslookup may hide.

Frequently Asked Questions

Why does dig return SERVFAIL but my browser loads the site?

Your browser may be using a different DNS resolver (like a system-level cache or a DoH/DoT resolver) than the one dig is querying by default. Try dig @8.8.8.8 example.com to see if the public resolver works. If it does, the problem is with your local DNS server or its upstream forwarders.

What does “dig +trace” show that a normal dig doesn’t?

A normal dig only shows the final response from your configured resolver. +trace starts at the root servers and follows the delegation chain: root → TLD → authoritative. This shows you exactly which server fails to respond or returns a wrong answer, which is essential for finding delegation errors or missing glue records.

How do I check if a DNS change has propagated?

Query the authoritative name server directly using dig @ns1.example.com example.com. If the authoritative server returns the new record but your resolver still shows the old one, the change hasn’t propagated yet and you need to wait for the TTL to expire. Also check the TTL in the answer — a high TTL means caches will hold the old record longer.

Why does dig show a CNAME in the ANSWER section?

A CNAME record means the queried name is an alias for another name. The ANSWER section will show both the CNAME and the final A/AAAA record for the target. This is normal and not an error. If you want to skip the CNAME and see the final IP, use dig +short.

What is the “EDNS” section in dig output?

EDNS (Extension Mechanisms for DNS) is a protocol extension that allows larger UDP packets and DNSSEC records. The EDNS section shows the maximum UDP payload size the server can handle. If you see EDNS: version: 0, flags:; udp: 4096, that’s normal. If you see no EDNS section, the server may not support it, which can cause DNSSEC validation failures or truncated responses.

How do I find the authoritative name server for a domain?

Use dig NS example.com to get the list of name servers. Then query one of those directly with dig @ns1.example.com example.com to get the authoritative answer. If the NS records are missing or wrong, you’ll see a SERVFAIL or a response without the aa flag.

Related

• Foreign Spies Recruit on Social Media? How It Works
• AI Knowledge Gap Detection: Skills Inference Guide
• AI Deciding vs Generating: What Changes