VMware ESXi and vSphere Cluster Management

Using the dig Command for DNS Lookups in Linux

Learn how to use Linux dig for DNS lookups, inspect response sections, query record types, perform reverse lookups, compare resolvers, and run batch queries.

dig, short for Domain Information Groper, is a command-line DNS query and diagnostic utility. It asks DNS servers questions and displays detailed, protocol-level results. DNS, the Domain Name System, stores records that connect domain names with IPv4 addresses, IPv6 addresses, mail servers, name servers, aliases, and other data.

Compared with simpler tools such as host, dig offers more control over the DNS server, record type, output sections, timeout behavior, and batch input. This makes it useful for Linux troubleshooting, DNS administration, development, and learning how DNS works.

Basic DNS lookup syntax

The general form is:

dig [options] domain [record-type]

A lookup without a record type normally requests an A record. An A record maps a hostname to an IPv4 address.

dig example.com

You can request the same record explicitly with either a direct type name or the -t option:

dig example.com A
dig -t A example.com

Use a documentation domain such as example.com when practicing. Real domains can return different answers over time because of caching, load balancing, and CDN behavior.

Understanding standard dig output

A normal response is divided into several sections. A query does not necessarily contain every section or every type of record.

Header — Shows the query ID, response status, flags, and counts for the sections that follow. Common flags indicate whether the message is a response, whether recursion was requested or available, and whether the responding server is authoritative.

Question — Shows the requested DNS name, class, and record type. The class IN means the Internet class, which is the standard class used for ordinary public DNS.

Answer — Contains resource records returned for the requested name and type. A resource record includes a name, TTL, class, type, and record-specific data.

Authority — May contain delegation or authoritative-server information. For example, a negative response may identify name servers responsible for the relevant zone.

Additional — May provide supporting data, such as the IPv4 or IPv6 addresses of name servers listed elsewhere in the response.

Query statistics — Shows how long the query took, which server replied, and sometimes the response size. These details help identify latency and determine which resolver supplied the answer.

; <<>> DiG example.com A
;; QUESTION SECTION:
;example.com.        IN      A

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

;; Query time: 20 msec
;; SERVER: DNS_SERVER_ADDRESS#53
;; WHEN: ...

In this example, 3600 is the TTL, or time to live. It indicates how long a resolver may cache the record before asking again. The displayed address is illustrative; actual DNS answers can vary.

Controlling output verbosity

By default, dig displays comments, sections, and statistics that are useful for diagnosis but sometimes inconvenient in scripts.

+noall hides the usual output sections. Add individual display flags to show only what you need. The most common concise combination is:

dig example.com +noall +answer

+answer enables the answer section, so the combined command shows only returned answer records. It may produce no visible record if the response has no answer for the requested type.

Output flags can be combined. For example, you can suppress the normal sections and enable selected sections such as the answer and authority sections:

dig example.com +noall +answer +authority

Querying common DNS record types

Specify a type with -t TYPE or, where appropriate, place the type after the domain:

A — Maps a name to an IPv4 address. Example: dig example.com A

AAAA — Maps a name to an IPv6 address. Example: dig -t AAAA example.com

MX — Lists mail exchange hosts and their preference values. Lower preference values are normally preferred. Example: dig -t MX example.com

NS — Identifies name servers for a DNS zone. Example: dig -t NS example.com

CNAME — Identifies an alias pointing to another canonical DNS name. Example: dig -t CNAME www.example.com

TXT — Stores text data used for domain verification, SPF-related policy, DKIM, DMARC, and service configuration. Example: dig -t TXT example.com

SOA — Shows start-of-authority data for a zone, including the primary authority name, serial number, refresh interval, retry interval, expire interval, and negative-cache timing. Example: dig -t SOA example.com

PTR — Maps an IP address to a hostname and is normally requested with reverse lookup syntax. Example: dig -x 192.0.2.25

For example, an MX response contains a preference number and a mail-host name. Query that mail host separately for A and AAAA records to find its addresses.

dig -t MX example.com
dig -t NS example.com
dig -t TXT example.com
dig -t SOA example.com
dig -t AAAA example.com

An ANY request can be written as follows:

dig -t ANY example.com

Modern DNS servers commonly restrict, minimize, or refuse ANY responses. An ANY request is therefore not a reliable way to enumerate all records in a zone. Query the specific record types you need instead.

Reverse DNS lookups

A reverse DNS lookup starts with an IP address and requests its PTR record. The -x option constructs the appropriate reverse-DNS name automatically:

dig -x 192.0.2.25

IPv4 reverse names use the in-addr.arpa namespace. The address octets are reversed in that namespace. IPv6 reverse names use ip6.arpa and represent the address as reversed hexadecimal nibbles.

An address may have no PTR record. Also, forward DNS and reverse DNS are managed independently: a hostname can resolve to an address without that address resolving back to the same hostname.

Selecting a DNS server

Place @server before the domain to send the query to a particular resolver or authoritative server:

dig @DNS_SERVER_ADDRESS example.com A

Replace DNS_SERVER_ADDRESS with an authorized resolver available in your environment. Using a placeholder avoids assuming a particular public resolver. A selected resolver might be a local router, corporate DNS service, VPN resolver, or an authoritative server.

Comparing servers helps when local resolution differs from another network. Differences can result from split-horizon DNS, cached data, geographic routing, CDN policy, propagation state, or different recursive resolvers. The SERVER line in the statistics identifies which server answered.

Batch mode with a file

The -f option reads multiple DNS requests from a file. Use one valid query request per line:

cat > queries.txt <<'EOF'
example.com A
example.com AAAA
example.com MX
www.example.com CNAME
EOF

dig -f queries.txt

Batch mode is useful for checking a group of domains, comparing expected records, or verifying a DNS migration. Keep each line in the same general form as a command's domain and record-type arguments. Test a single line first if a batch file produces unexpected output.

Interpreting DNS responses

NOERROR — The DNS query completed successfully. It does not guarantee that the answer section contains a record of the requested type.

NXDOMAIN — The responding server says the requested DNS name does not exist. Check spelling, the subdomain, and the intended DNS zone.

SERVFAIL — The resolver could not complete the query. Possible causes include DNSSEC validation problems, broken authoritative configuration, upstream failures, or a resolver problem.

REFUSED — The server understood the query but declined to answer, commonly because of access policy or recursion restrictions.

Timeout — No response arrived within the retry period. The server may be unreachable, blocked, overloaded, or unavailable on the selected network path.

NOERROR with no answer records — The name may exist but have no record of the requested type. This is different from NXDOMAIN. It is sometimes called an empty or NODATA response.

Look at the answer record's TTL when comparing results. A resolver can return a cached value whose remaining TTL is lower than the authoritative record's configured TTL. Multiple addresses can also be intentional, supporting DNS load balancing or CDN distribution.

Practical DNS troubleshooting workflow

  1. Start with a normal A or AAAA lookup: dig example.com A or dig example.com AAAA.
  2. Inspect the header status, flags, answer records, TTL values, and server statistics.
  3. Repeat the query against a selected, authorized resolver: dig @DNS_SERVER_ADDRESS example.com A.
  4. Check delegation and zone authority with dig -t NS example.com and dig -t SOA example.com.
  5. Use +noall +answer when collecting evidence or feeding simple checks, but retain a full response when diagnosing delegation or failures.
  6. Use reverse lookup only when validating PTR configuration for an address: dig -x 192.0.2.25.

NXDOMAIN

If a lookup reports NXDOMAIN, the responding server says that the name does not exist. Check the spelling and subdomain, then inspect the zone's name servers:

dig example.com
dig -t NS example.com

NOERROR with an empty answer

The name can exist while lacking the requested record type. Check other likely types and inspect the full response:

dig example.com A
dig example.com AAAA
dig example.com CNAME

A CNAME, delegation response, or negative answer may require reading the authority section as well as the answer section.

SERVFAIL

SERVFAIL means the resolver could not obtain or validate a usable answer. Possible causes include DNSSEC validation errors, broken delegation, unreachable upstream servers, or resolver faults. Compare a selected resolver and inspect NS and SOA data:

dig @DNS_SERVER_ADDRESS example.com
dig -t NS example.com
dig -t SOA example.com

Timeout

A timeout can indicate an unreachable server, firewall filtering, overload, or a network-path problem. Limit retries during testing:

dig @DNS_SERVER_ADDRESS example.com
dig +time=2 +tries=1 @DNS_SERVER_ADDRESS example.com

Missing reverse record

If a reverse lookup returns no PTR record, the organization responsible for the address range may not have configured reverse DNS. This does not by itself prove that forward DNS is incorrect.

dig -x 192.0.2.25

Different answers from different servers

Different answers can be caused by cache state, propagation, split-horizon DNS, geographic routing, load balancing, or CDN policy. Compare the server names, TTL values, status, and authority information:

dig @DNS_SERVER_ONE example.com A
dig @DNS_SERVER_TWO example.com A
dig example.com +noall +answer

Exam-relevant notes

  • dig means Domain Information Groper and is a detailed DNS query and troubleshooting tool.
  • A query without a type normally requests an A record; AAAA requests IPv6 addresses.
  • -t TYPE selects a record type, while @server selects the DNS server.
  • -x performs a reverse lookup for a PTR record.
  • +noall +answer produces concise answer-only output.
  • NOERROR can still mean an empty answer; NXDOMAIN means the name does not exist.
  • NS records identify name servers for a zone, while the resolver shown in the statistics is the server that answered the query.
  • ANY queries are not dependable for listing all records because modern servers may restrict or refuse them.

For a related comparison, see the dig command reference.