How to Read DNS Lookup Output (dig, nslookup, and What It All Means)

You run a DNS lookup, and a wall of text scrolls past: ANSWER SECTION, flags, TTLs, record types, a status code, some numbers you don't recognize. Most people glance at the IP address they were looking for and ignore the rest. But that "rest" is full of useful information: whether the answer is authoritative, how long it will be cached, whether DNSSEC validated, and clues about why something isn't resolving the way you expect.

Learning to read DNS lookup output turns these tools from black boxes into precise diagnostic instruments. Whether you use dig on the command line, nslookup, or a web-based lookup tool, the underlying information is the same, and once you can read it, troubleshooting DNS becomes far less mysterious.

This guide walks through what each part of DNS lookup output means, using dig as the primary example since it's the most detailed, then covering nslookup and what to look for when things go wrong.

A Complete dig Output, Annotated

Here's a typical dig command and its full output. We'll break down every section.

$ dig example.com A

; <<>> DiG 9.18.1 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14823
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            3600    IN      A       93.184.216.34

;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Jun 19 10:15:42 UTC 2026
;; MSG SIZE  rcvd: 56

The Header Line

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14823

This is the most important line for diagnosing problems. The key field is status:

• NOERROR means the query succeeded. (Note: NOERROR doesn't always mean you got the record you wanted, it can also mean "the name exists but has no record of this type.")
• NXDOMAIN means the domain name does not exist. If you see this for a domain you expect to work, the name is wrong, the domain is unregistered or expired, or there's a delegation problem.
• SERVFAIL means the server failed to complete the query. This often indicates a DNSSEC validation failure, a broken delegation, or a problem at the authoritative server. SERVFAIL is one of the most common symptoms of DNSSEC misconfiguration.
• REFUSED means the server refused to answer, often a permissions or configuration issue.

The opcode: QUERY is the operation type (almost always QUERY), and id is a transaction identifier matching the query to its response.

The Flags

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

The flags tell you about the nature of the response:

• qr (query response): this is a response, not a query.
• aa (authoritative answer): the responding server is authoritative for this domain. If you query an authoritative nameserver directly, you'll see aa. If you query a recursive resolver that fetched the answer on your behalf, you won't, the answer came from cache or recursion, not from authority. This distinction matters, and we cover it fully in our authoritative vs recursive DNS guide.
• rd (recursion desired): the query asked the server to recurse.
• ra (recursion available): the server is willing to recurse.
• ad (authenticated data): DNSSEC validation succeeded. If you see ad, the resolver cryptographically validated the answer. Its absence on a signed domain can indicate a validation problem.

The counts (QUERY: 1, ANSWER: 1, ...) tell you how many records are in each section of the response.

The Question Section

;; QUESTION SECTION:
;example.com.                   IN      A

This simply echoes back what you asked: the name (example.com.), the class (IN for Internet), and the record type (A). It confirms the server understood your query. The trailing dot on the name indicates it's fully qualified.

The Answer Section

;; ANSWER SECTION:
example.com.            3600    IN      A       93.184.216.34

This is what you came for. Reading left to right:

• example.com. is the name that was queried.
• 3600 is the TTL in seconds, how long this record can be cached. If you query a recursive resolver repeatedly, you'll see this number counting down as the cached entry ages, which is a handy way to tell you're getting a cached answer. We explain TTL behavior in our TTL best practices guide.
• IN is the class (Internet).
• A is the record type.
• 93.184.216.34 is the actual data, the IP address.

If a domain has multiple A records (round-robin), you'll see multiple lines here. For other record types, the data column changes accordingly: an MX record shows a priority and mail server, a TXT record shows quoted text, a CNAME shows the alias target.

The Authority and Additional Sections

When present, the AUTHORITY SECTION lists the authoritative nameservers for the domain (NS records). The ADDITIONAL SECTION provides extra helpful records, often the IP addresses (glue records) of the nameservers mentioned in the authority section, saving an extra lookup.

The OPT PSEUDOSECTION you may see relates to EDNS (Extension Mechanisms for DNS), which enables features like larger UDP packet sizes and DNSSEC. It's not a real record, just protocol-level information.

The Footer: Timing and Server Info

;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Jun 19 10:15:42 UTC 2026
;; MSG SIZE  rcvd: 56

• Query time is how long the lookup took. A high value can indicate a slow resolver or a distant authoritative server.
• SERVER is which resolver answered, and the port (53 is standard DNS). This tells you whether you queried your local resolver, a public one, or an authoritative server directly.
• WHEN is the timestamp of the query.
• MSG SIZE is the response size in bytes.

Useful dig Variations

A few common dig commands and what they're for:

• dig example.com → defaults to an A record lookup.
• dig example.com MX → look up mail servers. Swap MX for any type (TXT, NS, SOA, CAA, AAAA).
• dig example.com ANY → request all record types (though many servers now limit ANY responses).
• dig +short example.com → just the answer data, no surrounding detail. Good for scripts.
• dig +trace example.com → trace the resolution from the root servers down, showing each delegation step. Excellent for diagnosing delegation problems.
• dig @8.8.8.8 example.com → query a specific resolver (here, Google's), useful for comparing answers across resolvers.
• dig +dnssec example.com → request DNSSEC records, showing RRSIG signatures and the ad flag if validation succeeds.

The +trace and @resolver variations are especially powerful for troubleshooting, which we cover more in our DNS troubleshooting guide.

Reading nslookup Output

nslookup is available on Windows, macOS, and Linux, and is often more familiar to Windows users. Its output is simpler but conveys similar core information:

$ nslookup example.com

Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34

Key things to read:

• Server / Address at the top is the resolver that answered.
• Non-authoritative answer means the response came from a recursive resolver's cache or recursion, not directly from an authoritative server. (If it were authoritative, this line would be absent.) This is the nslookup equivalent of the missing aa flag in dig.
• Name / Address is the result.

nslookup can also query specific types (nslookup -type=MX example.com) and specific servers (nslookup example.com 8.8.8.8), similar to dig. While dig gives more detail, nslookup is perfectly capable for everyday checks.

Diagnosing Common Problems From the Output

Here's how to read the output when something is wrong:

• status: NXDOMAIN: the name doesn't exist. Check for typos, verify the domain is registered and not expired, and confirm the delegation is correct.
• status: SERVFAIL: commonly a DNSSEC validation failure or a broken authoritative server. Try dig +cd (checking disabled) to bypass DNSSEC validation; if it works with +cd but fails without, you've found a DNSSEC problem.
• NOERROR but empty ANSWER section: the name exists but has no record of the type you asked for. For example, querying an AAAA (IPv6) record for a domain that only has IPv4 returns NOERROR with no answer.
• Missing aa flag when querying an authoritative server: you may not be querying the server you think you are, or the server isn't authoritative for that zone (possible lame delegation).
• TTL counting down on repeated queries: you're hitting a cache. Query the authoritative server directly (find it via the NS records) to see the true current value.
• Different answers from different resolvers: could indicate propagation in progress (a recent change still spreading) or, more concerningly, a problem. We explain propagation in our DNS propagation guide.

Using a Web-Based Lookup Tool

Command-line tools are powerful, but a web-based DNS lookup gives you the same core information without needing terminal access, and queries from a neutral external vantage point rather than your local network. This external perspective matters: your local resolver might have a cached or different answer than what the rest of the world sees.

The DNS lookup tool at dnsassistant.com/tools lets you query any record type for any domain and see the results clearly, including the values, types, and TTLs, without parsing raw dig output. It's an easy way to check what your domain is actually serving from outside your own network.

How DNS Assistant Helps

Reading lookup output is essential for one-off troubleshooting, but it's a manual snapshot. You only see what's happening at the moment you run the command. DNS Assistant performs these lookups continuously and interprets the results for you:

• Continuous monitoring runs the equivalent of these lookups around the clock, so you don't have to manually check.
• Change detection alerts you when any record's value changes, catching the things a one-time lookup would only reveal if you happened to run it at the right moment.
• DNSSEC validation automatically checks the ad-flag equivalent and the full chain of trust, catching the SERVFAIL-causing problems before they affect users.
• Multi-vantage perspective with alerting via email, Slack, Microsoft Teams, webhooks, and SMS.

Think of manual lookups as the diagnostic tool you reach for when investigating, and DNS Assistant as the continuous monitor that tells you when you need to investigate in the first place.

Try It Yourself

Use the DNS lookup tool at dnsassistant.com/tools to query your domain's records and practice reading the results. Run a Free Domain Risk Report for a comprehensive interpreted view of your DNS configuration.

For continuous monitoring that reads your DNS for you and alerts on changes, sign up at dnsassistant.com.