Eric Campbell 5 min read Linux

Linux dig and nslookup: DNS Query Tools

DNS resolution failures account for a significant portion of application outages, yet many developers reach for `ping` or browser developer tools when troubleshooting connectivity issues. This...

Key Insights

  • dig provides more detailed DNS information and better scripting capabilities than nslookup, making it the preferred tool for serious troubleshooting and automation
  • Understanding DNS query paths with dig +trace reveals delegation issues that simple lookups miss, essential for diagnosing propagation problems
  • Both tools serve different purposes: use nslookup for quick interactive queries and dig for detailed analysis, scripting, and production debugging

Introduction to DNS Query Tools

DNS resolution failures account for a significant portion of application outages, yet many developers reach for ping or browser developer tools when troubleshooting connectivity issues. This approach wastes time and provides incomplete information. Professional system administrators rely on dedicated DNS query tools that expose the full resolution process, cache behavior, and authoritative responses.

Two command-line tools dominate DNS troubleshooting on Linux systems: dig (Domain Information Groper) and nslookup (Name Server Lookup). While both query DNS servers and return results, they differ significantly in output format, feature sets, and practical applications. Understanding when and how to use each tool separates competent administrators from those who guess at DNS problems.

nslookup Basics

nslookup originated in the 1980s and remains available on virtually every operating system. Its simplicity makes it accessible for quick lookups, though the BIND maintainers officially deprecated it years ago in favor of dig and host. Despite deprecation, nslookup persists in common use.

The most basic usage queries your system’s default DNS resolver:

nslookup google.com

This returns the server used for resolution and the resulting IP addresses:

Server:     192.168.1.1
Address:    192.168.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.185.46

To query a specific DNS server instead of your default resolver, append the server’s IP address:

nslookup google.com 8.8.8.8

This proves invaluable when comparing responses from different DNS providers or testing whether your local resolver caches stale data.

Reverse DNS lookups translate IP addresses back to hostnames:

nslookup 8.8.8.8

Returns:

Server:     192.168.1.1
Address:    192.168.1.1#53

Non-authoritative answer:
8.8.8.8.in-addr.arpa    name = dns.google.

nslookup also provides an interactive mode by running the command without arguments. This mode allows multiple queries without repeatedly typing the command:

nslookup
> server 1.1.1.1
> set type=MX
> gmail.com
> set type=TXT
> gmail.com
> exit

Interactive mode suits exploratory troubleshooting when you need to test multiple record types or servers quickly. However, the output format and limited scripting capabilities make nslookup unsuitable for automation.

dig Command Fundamentals

dig produces structured, parseable output designed for both human reading and script consumption. It’s part of the BIND DNS software suite and has become the standard DNS troubleshooting tool on Unix-like systems.

A basic query demonstrates dig’s verbose output:

dig google.com

This returns comprehensive information including query time, server used, flags, and the full DNS response:

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

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

;; ANSWER SECTION:
google.com.     300 IN  A   142.250.185.46

;; Query time: 23 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Mon Jan 15 14:30:22 UTC 2024
;; MSG SIZE  rcvd: 55

For quick lookups where you only need the answer, use the +short option:

dig google.com +short

Returns simply:

142.250.185.46

This format excels in scripts and one-liners. Query specific record types by appending the type:

dig google.com MX
dig google.com AAAA
dig google.com TXT

To query a specific nameserver, use the @ syntax:

dig @8.8.8.8 google.com

This proves essential when comparing authoritative nameserver responses against your recursive resolver’s cached data.

Advanced dig Features

dig’s real power emerges with advanced options that expose DNS infrastructure details invisible to basic queries.

The +trace option follows the complete DNS delegation chain from root servers through TLD servers to authoritative nameservers:

dig google.com +trace

This produces output showing each step:

.           518400  IN  NS  a.root-servers.net.
.           518400  IN  NS  b.root-servers.net.
...
com.        172800  IN  NS  a.gtld-servers.net.
...
google.com.     172800  IN  NS  ns1.google.com.
google.com.     300    IN  A   142.250.185.46

Tracing reveals where DNS delegation breaks, identifies propagation delays, and exposes configuration errors in nameserver hierarchies.

Query all available record types with ANY (though many authoritative servers now refuse these queries to prevent abuse):

dig google.com ANY

Reverse lookups use the -x flag:

dig -x 142.250.185.46

For bulk queries, create a file with one domain per line and use -f:

echo -e "google.com\ngithub.com\nstackoverflow.com" > domains.txt
dig -f domains.txt +short

This approach efficiently queries hundreds or thousands of domains in scripts.

Comparing Output and Use Cases

The same query with both tools illustrates their fundamental differences:

nslookup github.com

Server:     192.168.1.1
Address:    192.168.1.1#53

Non-authoritative answer:
Name:   github.com
Address: 140.82.121.4

dig github.com

;; ANSWER SECTION:
github.com.     60  IN  A   140.82.121.4

;; Query time: 15 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)

dig exposes TTL values (60 seconds here), query timing, and structured sections. This information matters when troubleshooting caching issues or performance problems.

Use nslookup for:

  • Quick interactive exploration
  • Environments where dig isn’t installed
  • Simple lookups where detailed output adds no value

Use dig for:

  • Production troubleshooting requiring detailed information
  • Scripts and automation
  • Performance analysis
  • DNSSEC validation
  • Tracing delegation paths

Practical Troubleshooting Scenarios

Checking DNS propagation across multiple servers after making changes:

for server in 8.8.8.8 1.1.1.1 208.67.222.222; do
    echo "Checking $server:"
    dig @$server example.com +short
done

This quickly identifies whether all major public DNS resolvers see your updated records.

Validating email configuration by checking MX and TXT records:

dig example.com MX +short
dig example.com TXT | grep "v=spf1"
dig _dmarc.example.com TXT +short

These commands verify mail server configuration and anti-spoofing policies in seconds.

DNSSEC validation ensures DNS responses haven’t been tampered with:

dig example.com +dnssec

Look for the ad (authenticated data) flag in the response header and RRSIG records in the answer section.

Diagnosing slow resolution by comparing query times:

dig example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

Significant differences indicate problems with your local resolver.

Finding authoritative nameservers for direct queries:

dig example.com NS +short
dig @ns1.example.com example.com

Querying authoritative servers bypasses caching and shows the canonical DNS data.

Conclusion and Best Practices

Master both tools but default to dig for serious work. Its structured output, comprehensive options, and scripting capabilities make it indispensable for professional DNS troubleshooting. Keep nslookup in your toolkit for quick interactive sessions and environments where dig isn’t available.

When troubleshooting DNS issues, always query authoritative nameservers directly to distinguish between propagation delays and configuration errors. Use +trace to understand delegation chains. Check multiple public resolvers to identify caching or resolver-specific problems.

Build a collection of DNS troubleshooting one-liners using dig and shell scripting. Automate repetitive checks like monitoring propagation after DNS changes or validating email security records across your domain portfolio. The time invested in learning these tools pays dividends every time you diagnose a DNS issue in minutes rather than hours.

DNS problems rarely announce themselves clearly. Applications timeout, email bounces, or services become unreachable. Effective use of dig and nslookup transforms mysterious failures into concrete, fixable configuration issues.

Liked this? There's more.

Every week: one practical technique, explained simply, with code you can use immediately.