How to Use the dig Command in Linux to Troubleshoot DNS Records and Nameservers

Domain Name System (DNS) misconfigurations, propagation delays, and faulty nameserver responses are among the most frequent causes of website downtime, email delivery failures, and unexpected network timeouts. While basic tools like nslookup and host provide high-level IP lookups, they lack the granular protocol inspection required for deep technical troubleshooting. In Linux systems, the definitive command-line utility for querying DNS servers and auditing records is dig (Domain Information Grokler). Developed as part of the BIND 9 suite, dig provides comprehensive control over query flags, authority sections, and record types.

Installing the dig Utility on Linux

The dig binary is distributed within the standard DNS utilities package on major Linux distributions:

On Ubuntu, Debian, and Linux Mint:

sudo apt update
sudo apt install dnsutils -y

On Fedora, RHEL, CentOS, and Rocky Linux:

sudo dnf install bind-utils -y

On Arch Linux and Manjaro:

sudo pacman -S bind

Understanding Standard dig Output Structure

When you execute a basic DNS query:

dig example.com

The terminal returns an informative multi-section report consisting of:

• Header: Displays the dig version, technical flags (such as qr, rd, ra), and the overall query response status (NOERROR, NXDOMAIN, or SERVFAIL).
• QUESTION SECTION: Echoes the requested domain name, protocol class (usually IN for Internet), and record type queried (default is A).
• ANSWER SECTION: Contains the actual response, including the resolved IP address, record type, and remaining Time-to-Live (TTL) in seconds.
• AUTHORITY & ADDITIONAL SECTIONS: Lists authoritative nameservers responsible for the zone and glue records.
• Footer Statistics: Documents query time in milliseconds, the specific server IP that handled the resolution, and timestamp details.

Querying Specific DNS Record Types

You can instruct dig to query specific DNS resource record types by appending the record identifier after the hostname:

1. Querying IPv6 (AAAA) Records

dig example.com AAAA

2. Querying Canonical Name (CNAME) Records

dig www.example.com CNAME

3. Querying Mail Exchange (MX) Records

To inspect mail server priority routing and hostname assignments:

dig example.com MX

4. Querying Verification and SPF (TXT) Records

To audit SPF, DKIM, DMARC, or Google site verification strings:

dig example.com TXT

5. Querying Authoritative Nameservers (NS)

dig example.com NS

Targeting Specific Nameservers with the @ Symbol

By default, dig queries the local DNS resolver defined in your system’s /etc/resolv.conf file or managed by systemd-resolved. When troubleshooting DNS propagation issues or checking if a freshly updated record is live, you should query external public resolvers directly using the @ prefix:

Querying Cloudflare Public DNS (1.1.1.1):

dig @1.1.1.1 example.com

Querying Google Public DNS (8.8.8.8):

dig @8.8.8.8 example.com

Querying your domain’s authoritative nameserver directly (bypassing all public cache TTLs):

dig @ns1.yourdomainhost.com example.com

Performing Reverse DNS Lookups (rDNS) with the -x Flag

To verify which domain name maps back to a specific IP address (PTR record), pass the -x flag followed by the IP:

dig -x 8.8.8.8

The Answer Section returns the corresponding Pointer (PTR) record (such as dns.google.).

Stripping Verbose Output with the +short Flag

When integrating dig into automated Bash scripts or monitoring cron jobs, you rarely need the full verbose header output. The +short argument strips headers, comments, and statistics, returning only raw values:

dig example.com +short

To inspect TTL values without full commentary, use +noall +answer:

dig example.com +noall +answer

Tracing Full DNS Resolution Hierarchies with +trace

When a domain fails to resolve completely and you need to determine which layer in the DNS hierarchy is failing, pass the +trace argument:

dig example.com +trace

This command queries the root DNS nameservers (.), follows delegations down through the Top-Level Domain (TLD) nameservers (such as .com), and finally contacts your domain’s authoritative name server, detailing every delegation step.

dig vs nslookup vs host Utility Comparison

Feature	dig	nslookup	host
Output Detail	Comprehensive, raw protocol output	Formatted, high-level summary	Concise, readable one-liners
Scripting Friendliness	High (+short flag)	Low (inconsistent across OS)	Moderate
Full Resolution Trace	Yes (+trace argument)	No	No
BIND Maintenance	Active (ISC / BIND 9 suite)	Legacy / deprecated by ISC	Active (ISC)
Custom Protocol Probing	TCP, UDP, EDNS, DNSSEC	Basic UDP/TCP	Basic UDP/TCP

Frequently Asked Questions

What does the status NXDOMAIN mean in a dig response?

NXDOMAIN (Non-Existent Domain) signifies that the queried domain name does not exist according to the authoritative nameserver responsible for the root or TLD zone.

How can I test if DNS queries work over TCP instead of UDP?

Append the +tcp argument to force connection over TCP port 53: dig +tcp example.com. This is useful for testing firewall policies when large DNSSEC responses exceed standard UDP buffer limits.

How do I query DNSSEC validation records with dig?

Include the +dnssec flag to retrieve RRSIG, DNSKEY, and DS validation records: dig example.com +dnssec.