dig Command in Linux: DNS Lookup

When a domain does not resolve, a mail server rejects messages, or a DNS change seems stuck, you need to see what name servers are returning. The dig command gives you that view from the Linux terminal.

Dig (Domain Information Groper) is part of the BIND (Berkeley Internet Name Domain) suite of DNS utilities. It queries DNS name servers and shows records such as A, AAAA, MX, NS, TXT, CNAME, and PTR.

This guide covers the dig command with practical examples and detailed explanations of the most common options.

Syntax #

dig [@server] [name] [type] [+queryoptions]

• @server - The IP address or hostname of the name server to query. If not specified, dig uses the servers listed in /etc/resolv.conf.
• name - The domain name to look up.
• type - The type of DNS record to query (e.g., A, AAAA, MX, NS, TXT). Defaults to A.
• +queryoptions - One or more query options such as +short, +noall, +answer, and +trace.

Installing dig #

To check if the dig command is available on your system, type:

dig -v

The output should look something like this:

DiG 9.20.26-1~deb13u1-Debian

If dig is not present on your system, the command above will print “dig: command not found”. Install the dig tool using your distribution’s package manager.

Install dig on Ubuntu, Debian, and Derivatives #

sudo apt update && sudo apt install bind9-dnsutils

On current Debian and Ubuntu releases the package is named bind9-dnsutils. The older name dnsutils still works, since it is kept as a virtual package that points at the same files.

Install dig on Fedora, RHEL, and Derivatives #

sudo dnf install bind-utils

Install dig on Arch Linux #

sudo pacman -S bind

Understanding the dig Output #

In its simplest form, when used to query a single host (domain) without any additional options, the dig command is pretty verbose.

In the following example, we are performing a DNS lookup on the linux.org domain:

dig linux.org

The output should look something like this:

; <<>> DiG 9.20.26-1~deb13u1-Debian <<>> linux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8757
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
linux.org.		112	IN	A	172.67.73.26
linux.org.		112	IN	A	104.26.14.72
linux.org.		112	IN	A	104.26.15.72

;; Query time: 3 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sun Aug 23 22:38:33 CEST 2026
;; MSG SIZE  rcvd: 86

DNS records change over time, so the addresses and TTL values you see will differ from the ones above. Let us go section by section and explain the output of the dig command:

1. The first line of the output prints the installed dig version, and the queried domain name. The second line shows the global options (by default, only cmd).

   output

   ; <<>> DiG 9.20.26-1~deb13u1-Debian <<>> linux.org
   ;; global options: +cmd

   If you do not want those lines to be included in the output, use the +nocmd option. It always applies to the whole run, so you cannot set it globally and then override it for a single lookup.

2. The next section includes technical details about the answer returned by the resolver. The header shows the opcode (the action performed by dig) and the response status. In this example, NOERROR means the resolver processed the query without a DNS protocol error. It does not guarantee that the answer section contains records.

   output

   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8757
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

   The counters at the end of the flags line tell you how many records each section of the reply holds. Here the resolver returned three answer records, no authority records, and one additional record.

   This section can be removed using the +nocomments option, which also disables some other section headers.

3. The “OPT” pseudo section is shown only in the newer versions of the dig utility. You can read more about the Extension Mechanisms for DNS (EDNS) here .

   output

   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags:; udp: 1232

   To exclude this section from the output, use the +noedns option.

4. In the “QUESTION” section, dig shows the query (question). By default, dig requests the A record.

   output

   ;; QUESTION SECTION:
   ;linux.org.			IN	A

   You can disable this section using the +noquestion option.

5. The “ANSWER” section provides the answer to our question. As we already mentioned, by default dig requests the A record. Here, we can see that the domain linux.org points to three IP addresses, which is common for sites sitting behind a content delivery network.

   output

   ;; ANSWER SECTION:
   linux.org.		112	IN	A	172.67.73.26
   linux.org.		112	IN	A	104.26.14.72
   linux.org.		112	IN	A	104.26.15.72

   The number after the domain name is the TTL, the number of seconds the record may stay in a resolver cache. Usually, you do not want to turn off the answer, but you can remove this section from the output using the +noanswer option.

6. The “AUTHORITY” section can identify authoritative servers in a referral or contain an SOA record in a negative answer. Our recursive reply does not include either, which is why the header counted AUTHORITY: 0. Caching resolvers that return a direct answer often leave this section empty.

   To see the authoritative servers for a domain, ask for them directly:

   Terminal

   dig linux.org ns +noall +answer

   output

   linux.org.		86400	IN	NS	lia.ns.cloudflare.com.
   linux.org.		86400	IN	NS	mark.ns.cloudflare.com.

   When the section is present, you can disable it with the +noauthority option.

7. The “ADDITIONAL” section carries records that may help use data from the other sections. For example, a referral can include address records for the name servers it names. Address records required to reach an in-bailiwick name server are called glue records.

   Our reply contains no ordinary additional records. The ADDITIONAL: 1 counter includes the OPT pseudo record shown earlier. Use +noadditional to hide ordinary records from the additional section.

8. The last section of the dig output includes statistics about the query.

   output

   ;; Query time: 3 msec
   ;; SERVER: 192.168.1.1#53(192.168.1.1)
   ;; WHEN: Sun Aug 23 22:38:33 CEST 2026
   ;; MSG SIZE  rcvd: 86

   You can disable this part with the +nostats option.

Print Only the Answer #

Generally, you would want to get only a short answer to your dig query.

Short Answer #

To get a short answer to your query, use the +short option:

dig linux.org +short

172.67.73.26
104.26.14.72
104.26.15.72

The output includes only the values returned for the A record. This form is convenient in scripts, but it is not completely parse-free: a lookup can return several lines or a CNAME followed by its target records, and NXDOMAIN produces no values even though dig exits with status zero. Use dig -r in scripts to ignore options from .digrc, and validate that the returned values match what your script expects.

Detailed Answer #

For a more detailed answer, turn off all the results using the +noall option and then turn on only the answer section with the +answer option:

dig linux.org +noall +answer

linux.org.		67	IN	A	172.67.73.26
linux.org.		67	IN	A	104.26.14.72
linux.org.		67	IN	A	104.26.15.72

Query a Specific Name Server #

By default, if no name server is specified, dig uses the servers listed in the /etc/resolv.conf file.

To specify a name server against which the query will be executed, use the @ (at) symbol followed by the name server IP address or hostname.

For example, to query the Google name server (8.8.8.8) for information about the linux.org domain, you would use:

dig linux.org @8.8.8.8

; <<>> DiG 9.20.26-1~deb13u1-Debian <<>> linux.org @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57934
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;linux.org.			IN	A

;; ANSWER SECTION:
linux.org.		300	IN	A	104.26.14.72
linux.org.		300	IN	A	172.67.73.26
linux.org.		300	IN	A	104.26.15.72

;; Query time: 34 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Aug 23 22:38:54 CEST 2026
;; MSG SIZE  rcvd: 86

Notice the SERVER line at the bottom: it confirms which resolver actually answered, which is the quickest way to tell whether your query went where you intended.

Query Record Types #

Dig allows you to perform any valid DNS query by appending the record type to the end of the query. In the following sections, we will show you examples of how to search for the most common records, such as A, AAAA, CNAME, TXT, MX, and NS.

A Records #

To get a list of all the address(es) for a domain name, use the a option:

dig +nocmd google.com a +noall +answer

google.com.		100	IN	A	142.251.142.110

If no DNS record type is specified, dig requests the A record by default. You can also query the A record without specifying the a option.

AAAA Records #

To query the IPv6 address of a domain, use the aaaa option:

dig +nocmd google.com aaaa +noall +answer

google.com.		300	IN	AAAA	2a00:1450:4017:815::200e

As IPv6 adoption continues to grow, querying AAAA records is useful for verifying that a domain has proper IPv6 connectivity.

CNAME Records #

A CNAME record points one name at another instead of at an address. To see what a name is an alias for, use the cname option:

dig +nocmd www.github.com cname +noall +answer

www.github.com.		2536	IN	CNAME	github.com.

The answer tells us that www.github.com is an alias for github.com, and a resolver looking for an address will follow that pointer and query github.com next. If the name you ask about has no CNAME, the answer section comes back empty, which is the normal result for a name that already holds A records of its own.

TXT Records #

Use the txt option to retrieve all the TXT records for a specific domain:

dig +nocmd google.com txt +noall +answer

google.com.		300	IN	TXT	"facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
google.com.		300	IN	TXT	"v=spf1 include:_spf.google.com ~all"
google.com.		300	IN	TXT	"docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"

TXT records are commonly used for SPF, DKIM, and domain ownership verification. Our email authentication guide explains what those records should contain and how receivers check them.

MX Records #

To get a list of all the mail servers for a specific domain, use the mx option:

dig +nocmd cisco.com mx +noall +answer

cisco.com.		1800	IN	MX	30 aer-mx-01.cisco.com.
cisco.com.		1800	IN	MX	10 alln-mx-01.cisco.com.
cisco.com.		1800	IN	MX	20 rcdn-mx-01.cisco.com.

The number before the mail server hostname is the priority. A lower number means higher priority, so a sending server tries alln-mx-01 first and falls back to the others only when it cannot deliver. Note that dig prints the records in whatever order the resolver returned them, not in priority order. Plenty of domains publish a single MX record, and that is perfectly valid.

NS Records #

To find the authoritative name servers for a specific domain, use the ns option:

dig +nocmd google.com ns +noall +answer

google.com.		84527	IN	NS	ns1.google.com.
google.com.		84527	IN	NS	ns2.google.com.
google.com.		84527	IN	NS	ns3.google.com.
google.com.		84527	IN	NS	ns4.google.com.

SOA Records #

The SOA (Start of Authority) record holds the administrative settings for a zone, including its serial number and the timers that secondary servers follow. Query it with the soa option:

dig +nocmd linux.org soa +noall +answer

linux.org.		1800	IN	SOA	lia.ns.cloudflare.com. dns.cloudflare.com. 2412685681 10000 2400 604800 1800

Those trailing numbers are hard to read on one line. Add the +multiline option and dig breaks the record apart and labels every field:

dig +nocmd linux.org soa +multiline +noall +answer

linux.org.		1800 IN	SOA lia.ns.cloudflare.com. dns.cloudflare.com. (
				2412685681 ; serial
				10000      ; refresh (2 hours 46 minutes 40 seconds)
				2400       ; retry (40 minutes)
				604800     ; expire (1 week)
				1800       ; minimum (30 minutes)
				)

The serial is the value to watch after a zone edit. When you change a record and the secondary servers still hand out the old data, comparing serials across name servers tells you which ones have picked up the change.

SRV Records #

SRV records advertise the host and port for a specific service, which is how clients find XMPP, SIP, or LDAP servers without a hardcoded address. The name you query follows the _service._protocol.domain form:

dig +nocmd _xmpp-server._tcp.jabber.org srv +noall +answer

_xmpp-server._tcp.jabber.org. 60 IN	SRV	30 30 5269 scarlet.jabber.org.

The four values after SRV are priority, weight, port, and target host. Here a client is told to connect to scarlet.jabber.org on port 5269.

CAA Records #

CAA records name the certificate authorities allowed to issue certificates for a domain. If a certificate request is being refused, this is the record to check first:

dig +nocmd google.com caa +noall +answer

google.com.		86400	IN	CAA	0 issue "pki.goog"

The issue tag means this record set authorizes pki.goog to issue certificates for the domain. An empty answer only tells you that no CAA record exists at the queried label. Certificate authorities follow aliases and search parent labels until they find the relevant CAA record set. Issuance is unrestricted by CAA only when that entire search returns no restrictive record. Our DNS record types guide covers what each of these record types is for in more detail.

ANY Queries #

The any option asks a resolver for an ANY response:

dig +nocmd google.com any +noall +answer

Modern public resolvers often return no useful answer or a minimal response for ANY queries. Per RFC 8482, DNS servers may refuse to provide a full record set and can return a small synthesized response instead. For a complete picture of a domain’s DNS records, query each record type individually.

Reverse DNS Lookup #

To query the hostname associated with a specific IP address, use the -x option.

For example, to perform a reverse lookup on 8.8.8.8, you would type:

dig -x 8.8.8.8 +noall +answer

As you can see from the output below, the IP address 8.8.8.8 is associated with the hostname dns.google:

8.8.8.8.in-addr.arpa.	57774	IN	PTR	dns.google.

dig builds the in-addr.arpa name for you by reversing the address octets, so you do not have to construct it yourself. Reverse records are published by whoever controls the IP block rather than by the domain owner, so an address with no PTR record is common and is not an error on your side.

Trace DNS Resolution Path #

The +trace option instructs dig to perform iterative queries from the root name servers down to the authoritative server. This is useful for debugging DNS resolution issues and understanding how a domain name is resolved:

dig google.com +trace

; <<>> DiG 9.20.26-1~deb13u1-Debian <<>> google.com +trace
;; global options: +cmd
.			86400	IN	NS	a.root-servers.net.
.			86400	IN	NS	b.root-servers.net.
;; Received 239 bytes from 192.168.1.1#53 in 12 ms

com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net) in 24 ms

google.com.		172800	IN	NS	ns1.google.com.
google.com.		172800	IN	NS	ns2.google.com.
;; Received 836 bytes from 192.5.6.30#53(a.gtld-servers.net) in 32 ms

google.com.		300	IN	A	142.251.142.110
;; Received 55 bytes from 216.239.34.10#53(ns2.google.com) in 18 ms

The output shows each step of the resolution: from the root servers (.), to the TLD servers (com.), to the authoritative name servers (ns1.google.com.), and finally the answer.

Verify DNSSEC #

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, protecting against spoofing and cache poisoning. The +dnssec option asks the resolver to include DNSSEC records, but dig does not validate those signatures itself:

dig cloudflare.com @1.1.1.1 +dnssec +noall +answer

cloudflare.com.		300	IN	A	104.16.132.229
cloudflare.com.		300	IN	A	104.16.133.229
cloudflare.com.		300	IN	RRSIG	A 13 2 300 ...

If DNSSEC is configured for the domain, you will see RRSIG records alongside the standard records. The signature fields are shortened above because their inception and expiration times rotate frequently. To check validation, query a trusted validating resolver and inspect the ad (Authenticated Data) flag in the header:

dig cloudflare.com @1.1.1.1 +dnssec | grep flags

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

The ad flag indicates that the resolver reports the answer as validated. This result is meaningful only when you trust the resolver and the path to it. For independent validation with the local DNSSEC trust anchors, use delv cloudflare.com.

Query Over TLS and HTTPS #

A plain DNS query travels in the clear on port 53, which means anyone on the path can read it. Public resolvers now accept encrypted queries as well, and dig can speak both encrypted transports since BIND 9.18. Add +tls-ca so dig validates the resolver certificate against the system certificate store. Without it, the traffic is encrypted but the resolver identity is not authenticated.

The +tls option sends the query over DNS over TLS (DoT), which defaults to port 853:

dig example.com @one.one.one.one +tls +tls-ca +noall +answer

example.com.		82	IN	A	172.66.147.243
example.com.		82	IN	A	104.20.23.154

The answer looks the same as a plain query, because only the transport changed. For DNS over HTTPS (DoH), use +https instead. It defaults to port 443 and sends the query as an HTTP POST request:

dig example.com @cloudflare-dns.com +https +tls-ca +noall +answer

These options are useful for confirming that a resolver really answers on its encrypted endpoints before you point a client or a whole network at it. If the command hangs or refuses to connect, the resolver either does not offer that transport or the port is blocked on the way out.

Bulk Queries #

If you want to query a large number of domains, you can add them in a file (one domain per line) and use the -f option followed by the file name.

In the following example, we are querying the domains listed in the domains.txt file:

lxer.com
linuxtoday.com
tuxmachines.org

dig -f domains.txt +short

66.232.124.26
172.67.188.196
104.21.49.12
94.76.207.113

The results are printed in the order the domains appear in the file. A domain that resolves to several addresses contributes one line per address, so the output is not always one line per domain.

The .digrc File #

The dig command’s behavior can be controlled by setting per-user options in the ${HOME}/.digrc file.

If the .digrc file is present in the user’s home directory, the options specified in it are applied before the command-line arguments.

For example, if you want to display only the answer section, open your text editor and create the following ~/.digrc file:

+nocmd +noall +answer

Troubleshooting #

dig returns SERVFAIL
SERVFAIL means the resolver could not complete the query. Common causes include unreachable authoritative servers, a lame delegation, and DNSSEC validation failures. Compare the normal response with one that asks the resolver to skip validation:

dig example.com @1.1.1.1
dig example.com @1.1.1.1 +cdflag

If the second command works while the first returns SERVFAIL, check the domain’s DNSSEC configuration. If several public resolvers fail in the same way, inspect the authoritative servers and delegation.

dig returns REFUSED
REFUSED means the server declined the query for policy reasons. Confirm that you are querying the intended server and that its access controls permit your address and query type. An authoritative-only server may also refuse recursive queries.

dig returns NXDOMAIN
NXDOMAIN means the exact DNS name you queried does not exist. The parent domain can still be registered and working, so check the full hostname for spelling errors and confirm that the intended record name was created.

No response or query timed out
This often points to a firewall, network, or server issue. Compare UDP with an explicit TCP query:

dig example.com @1.1.1.1
dig example.com @1.1.1.1 +tcp

If TCP works while the normal query times out, UDP port 53 may be blocked. If both fail, try another resolver before investigating the local firewall or network path.

The response is truncated
When a UDP reply has the tc flag, dig retries over TCP automatically. If the result is still truncated, make sure you did not use +ignore and confirm that outbound TCP port 53 is allowed. You can force TCP with:

dig example.com +tcp

Quick Reference #

For a printable quick reference, see the dig cheatsheet .

FAQ #

What is the difference between dig and nslookup?
Both tools query DNS servers, but dig provides more detailed output and is preferred for troubleshooting. nslookup has a simpler interactive mode and more readable output for quick checks. dig also supports advanced options like +trace and +dnssec that nslookup does not.

What does NXDOMAIN mean?
NXDOMAIN (Non-Existent Domain) means the exact DNS name in the query does not exist. It can refer to a missing hostname under a registered domain, so check the complete name rather than assuming the parent domain is unregistered.

How do I check DNS propagation?
After a planned change, query each authoritative name server directly and then compare public resolvers such as 8.8.8.8, 1.1.1.1, and 9.9.9.9. If the authoritative servers agree but public resolvers still return the previous value, their caches may not have expired. Different answers alone do not prove a propagation delay because GeoDNS, load balancing, split-horizon DNS, and EDNS Client Subnet can intentionally produce different results.

What does the TTL value mean in dig output?
TTL (Time To Live) is the number of seconds a resolver may cache a DNS record before consulting its source again. A lower TTL can shorten the cache transition for a planned change, but lower it before making the change. Resolvers that already cached the old record keep using its previous TTL until that cached copy expires.

Conclusion #

For a simpler interactive DNS lookup, see the nslookup command . To find out who owns a domain or when it expires rather than its DNS records, use the whois command . Our DNS record types guide explains when to use A, AAAA, CNAME, MX, TXT, and the other common records.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 1000+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page