Linux online course

Using the dig Command for DNS Lookups in Linux

Learn how to install and use Linux dig for DNS lookups, record types, reverse DNS, output interpretation, batch queries, and troubleshooting.

dig is a command-line DNS query utility. Its name expands to Domain Information Groper. It sends DNS queries to a resolver or authoritative nameserver and displays detailed information from the response.

This lesson covers basic lookups, DNS record types, reverse DNS, batch mode, output controls, response interpretation, and troubleshooting.

What dig Does

The Domain Name System (DNS) maps names to network-related records. For example, an A record can map a hostname to an IPv4 address, while an MX record identifies mail servers.

dig sends a DNS question and prints the server's response, including metadata, returned records, timing, and the server that answered. Its output is more detailed and flexible than the output of simpler tools such as host and nslookup. Those tools can be convenient for quick checks, while dig is especially useful when diagnosing DNS behavior or writing repeatable checks.

Installing and Accessing dig

dig is commonly packaged with the BIND DNS utilities rather than distributed as a standalone package. Install the package appropriate for your Linux distribution:

Debian or Ubuntu

sudo apt update && sudo apt install dnsutils

Fedora, RHEL, Rocky Linux, or AlmaLinux

sudo dnf install bind-utils

Arch Linux

sudo pacman -S bind

Confirm that the executable is available and display its version with:

dig -v

The command's version output confirms that your shell can locate and execute dig.

Basic DNS Lookup Syntax

The simplest form is:

dig domain-name

For example:

dig example.com

When no record type is specified, dig normally requests an A record, which maps a name to an IPv4 address.

To select a particular DNS server, put its address after an @ prefix:

dig @1.1.1.1 example.com

This sends the query to the resolver at 1.1.1.1 instead of relying on the system's configured resolver. A command can query a domain name, a selected record type, or a reverse-mapping address.

Understanding Standard dig Output

A normal response is divided into sections. The exact sections shown depend on the response and the command options.

Header and response status

The header identifies the dig version and shows response metadata. It commonly includes the response status, flags, question count, answer count, authority count, additional-record count, and global options.

NOERROR means the server processed the request successfully. It does not guarantee that the requested type has a record: a domain can exist and still return no records for a particular type. NXDOMAIN means the requested domain name does not exist according to the responding server. Other useful outcomes include SERVFAIL, which indicates that the server could not complete processing, and a timeout, which indicates that no usable response arrived in time.

Common flags

• qr: this message is a DNS response rather than a query.
• rd: recursion was requested by the client.
• ra: the responding server supports recursion.
• aa: the response is authoritative for the queried zone.
• tc: the response was truncated, often because it was too large for the transport being used.
• ad: the data was authenticated by DNSSEC validation performed by a validating resolver.

An answer from a recursive resolver is often non-authoritative. It may have come from that resolver's cache rather than directly from the authoritative nameserver.

Question section

The question section shows the requested DNS name, class, and type. The common class is IN, meaning Internet. For example, a question for example.com with type A asks for IPv4 address records for that name.

Answer section

The answer section contains returned records. A record line typically includes the record name, its TTL, class, type, and data. TTL means time to live: it indicates how long a resolver may cache the data before asking again.

Authority and additional sections

The authority section may identify authoritative nameservers for a zone, especially when a response contains delegation information or an error referral. An authoritative nameserver publishes the official records for a DNS zone. A DNS zone is an administratively managed portion of the DNS namespace.

The additional section supplies related records that can make the response usable without another lookup. For example, it may include IPv4 or IPv6 addresses for nameservers mentioned in the authority section.

Query statistics

The footer commonly reports the responding server, response time, timestamp, and DNS message size. These values help distinguish a valid but slow response from a network failure.

Controlling Displayed Output

For interactive inspection, full output is useful. For scripts or quick checks, suppress unnecessary sections.

dig example.com +noall +answer

+noall suppresses the usual output sections. +answer then restores only the answer section:

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

Options can be combined to tailor output for interactive use or scripts. When only the returned record data is needed, use the concise form:

dig example.com +short

+short omits most explanatory details and prints compact results. It is convenient, but the full response is better when investigating status, flags, TTLs, or delegation.

Querying DNS Record Types

Choose a record type with -t followed by the type name. The type can also be supplied as a direct argument in common dig syntax.

Common record examples

• A: Use this for IPv4 address lookups: dig example.com -t A.
• AAAA: Use this to inspect IPv6 information: dig example.com -t AAAA.
• MX: Each result includes a preference value. Lower values are preferred when sending mail: dig gmail.com -t MX.
• NS: This identifies nameservers delegated or authoritative for a zone: dig example.com -t NS.
• CNAME: This points an alias to a canonical name. After finding the target, query its A or AAAA records separately.
• TXT: Text records are commonly used for domain verification, SPF-related policy, DKIM-related data, and other application-defined values.
• SOA: The start-of-authority record includes zone administration and timing information such as the primary nameserver, serial number, refresh, retry, and expiration values.

ANY queries

An ANY query asks for broad information about a name:

dig example.com -t ANY

Modern authoritative servers may limit, minimize, or refuse ANY responses. Therefore, an incomplete ANY response does not prove that other records are absent. Individual queries such as A, AAAA, MX, or TXT are more dependable.

Reverse DNS Lookups

Reverse DNS starts with an IP address and looks for its PTR record, which maps that address to a hostname. Use the -x option:

dig -x 8.8.8.8

The address owner must correctly configure the reverse zone for a PTR result to exist. A PTR hostname is not proof that the hostname also resolves forward to the same IP address. To test that relationship, perform a separate forward lookup of the returned hostname and compare its A or AAAA result with the original address.

Batch Mode

Use -f to read multiple lookup requests from a file. Put one query per line in queries.txt:

example.com A
example.com MX
www.example.com CNAME
8.8.8.8

Process the file with:

dig -f queries.txt

Batch mode is useful for repeated checks, collecting several record types, or comparing DNS results over time. Keep one domain or lookup request on each line and use the same output-control options when a compact or script-friendly result is needed.

Useful dig Options

DNS Lookup Troubleshooting Workflow

1. Check whether the name exists

Start with a normal lookup and inspect the status and answer section:

dig example.com

NOERROR with an answer indicates that the requested record was returned. NXDOMAIN indicates that the queried name does not exist according to that responding server. Check spelling and confirm that you queried the intended fully qualified domain name.

2. Compare resolvers

A DNS resolver accepts client queries and may return cached data or recursively obtain an answer from other servers. Compare the configured resolver with a known public resolver:

dig example.com
dig @1.1.1.1 example.com

Compare the answer, TTL, flags, and SERVER field. Different results can be caused by resolver caching, propagation delays, split-horizon DNS, or resolver policy.

3. Follow delegation

Use +trace to follow delegation conceptually from root servers to the target zone:

dig example.com +trace

This can reveal where a delegation stops working or which authoritative nameserver is being reached. Trace results depend on network access to DNS servers and may not work when outbound DNS traffic is restricted.

4. Investigate common failures

If a query times out or reports no reachable servers, explicitly query a known reachable resolver, check whether DNS traffic is blocked, and review the system's resolver configuration. Malformed local settings can also prevent normal lookups.

If different resolvers disagree, record which resolver was used and compare TTLs and flags. Use +trace to inspect public delegation and query an authoritative nameserver directly where appropriate.

If a reverse lookup returns no PTR record, confirm the address and contact the ISP, cloud provider, or address-block owner responsible for the reverse zone. If an ANY query omits expected data, query each required record type explicitly instead of treating the abbreviated response as evidence that the records do not exist.

Practical Command Set

# Default IPv4 lookup
dig example.com

# Query a specific resolver
dig @1.1.1.1 example.com

# Show only the answer section
dig example.com +noall +answer

# Show concise record data
dig example.com +short

# Inspect mail servers
dig example.com -t MX

# Inspect nameservers
dig example.com -t NS

# Inspect IPv6 addresses
dig example.com -t AAAA

# Inspect an alias
dig www.example.com -t CNAME
dig canonical.example.com -t A

# Reverse lookup
dig -x 8.8.8.8

# Process saved queries
dig -f queries.txt

# Follow delegation
dig example.com +trace

Exam-Relevant Notes

• dig means Domain Information Groper and is used to inspect DNS queries and responses.
• A lookup without a type normally requests an A record.
• NOERROR means successful processing, not necessarily that the requested type has data.
• NXDOMAIN means the queried domain name does not exist according to the responding server.
• aa indicates an authoritative answer; its absence commonly means the answer came from a recursive resolver or another non-authoritative source.
• +noall +answer displays only the answer section, while +short provides a more concise result.
• -x performs a reverse PTR lookup, but a PTR result does not prove forward DNS consistency.
• Specific record-type queries are more reliable than ANY queries because servers may restrict ANY.

For related Linux command-line topics, see Linux command tutorials and how to show the full path of shell commands.