dig command allows you to query DNS servers and perform DNS lookups. You can also find the domain an IP address leads back to. We’ll show you how!
How the dig Command Works
People use the Linux
dig command to query Domain Name System (DNS) servers.
dig is an acronym for Domain Information Groper. With
dig, you can query DNS servers for information regarding various DNS records, including host addresses, mail exchanges, name servers, and related information. It was intended to be a tool for diagnosing DNS issues. However, you can use it to poke around and learn more about DNS, which is one of the central systems that keep the internet routing traffic.
The internet uses internet protocol (IP) addresses to identify “locations” around the web, but people use domain names. When you type a domain name into an application, like a web browser or SSH client, something has to translate from the domain name to the actual IP address. This is where the Domain Name System comes in.
When you use a domain name with any internet-connected program, your local router can’t resolve it (unless it’s cached from a previous request). So, your router queries either your Internet Service Provider’s (ISP) DNS server, or any other you’ve configured your system to use. These are called DNS precursor servers.
If the DNS server recently received the same request from someone else on the same computer, the answer might be in its cache. If that’s the case, it simply sends that same information back to your program.
If the DNS precursor server can’t locate the domain in its cache, it contacts a DNS root name server. A root server won’t hold the information required to resolve domain names to IP addresses, but it will hold lists of servers that can help with your request.
The root server looks at the top-level domain to which your domain name belongs, such as .COM, .ORG, .CO.UK, and so on. It then sends a list of the top-level domain servers that handle those types of domains back to the DNS precursor server. The DNS precursor server can then make its request once more, to a top-level domain server.
The top-level domain server sends the details of the authoritative name server (where the details of the domain are stored) back to the DNS precursor server. The DNS server then queries the authoritative name server that’s hosting the zone of the domain you originally entered into your program. The authoritative name server sends the IP address back to the DNS server, which, in turn, sends it back to you.
dig was already installed on our Ubuntu 18.04 and Fedora 30 computers. However, we had to install it on the Manjaro 18.04 computer with the following command:
sudo pacman -Sy bind-tools
Getting Started with dig
In our first example, we’ll return the IP addresses associated with a domain name. Often, multiple IP addresses are associated with a single domain name. This often happens if load balancing is used, for example.
We use the
+short query option, as shown below, which gives us a terse response:
dig howtogeek.com +short
All the IP addresses associated with the howtogeek.com domain are listed for us. At the other end of the spectrum, if we don’t use the
+short query option, the output is quite verbose.
So, we type the following to pipe it through
dig howtogeek.com | less
The output is displayed in
less, as shown below.
Here’s the full listing:
; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> howtogeek.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12017 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;howtogeek.com. IN A ;; ANSWER SECTION: howtogeek.com. 3551 IN A 18.104.22.168 howtogeek.com. 3551 IN A 22.214.171.124 howtogeek.com. 3551 IN A 126.96.36.199 howtogeek.com. 3551 IN A 188.8.131.52 ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Sun Mar 22 07:44:37 EDT 2020 ;; MSG SIZE rcvd: 106
Let’s dissect that piece by piece.
First, let’s take a look at we have in the Header:
; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> howtogeek.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12017 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
Now, here’s what all of that means:
- First line: The version of
digand the domain that was queried.
- Global options: As we’ll see, you can use
digto query multiple domains simultaneously. This line shows the options that have been applied to all of the domain queries. In our simple example, it was just the default
- Opcode: Query: This is the type of operation that was requested which, in this case, was a
query. This value can also be
iqueryfor an inverse query, or
statusif you’re just testing the state of the DNS system.
- Status: Noerror: There were no errors and the request was correctly resolved.
- ID: 12017: This random ID ties the request and response together.
- Flags: qr rd ra: These stand for
recursion desired, and
recursion available. Recursion is one form of DNS lookup (the other is iterative). You might also see
AA, which stands for Authoritative Answer, meaning an Authoritative Name Server provided the response.
- Query: 1: The number of queries in this session, which was one.
- Answer: 4: The number of answers in this response, which is four.
- Authority: 0: The number of answers that came from an Authoritative Name Server, which was zero in this case. The response was returned from the cache of a DNS precursor server. There will be no authoritative section in the response.
- Additional: 1: There is one piece of additional information. (Strangely, nothing is listed unless this value is two or higher.)
Next, we see the following in the Opt Pseudosection:
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494
Let’s break that down:
- EDNS: version 0: The version of Extension System for DNS that’s being used. EDNS transmits extended data and flags by extending the size of the User Datagram Protocol (UDP) packets. This is indicated by a variable size flag.
- flags: No flags are in use.
- udp: 4096: The UDP packet size.
In the Question section, we see the following:
;; QUESTION SECTION: ;howtogeek.com. IN A
Here’s what this means:
- howtogeek.com: The domain name we’re querying.
- IN: We’re making an internet class query.
- A: Unless we specify otherwise,
digwill request an A (address) record from the DNS server.
The Answer section contains the following four answers we received from the DNS server:
howtogeek.com. 3551 IN A 184.108.40.206 howtogeek.com. 3551 IN A 220.127.116.11 howtogeek.com. 3551 IN A 18.104.22.168 howtogeek.com. 3551 IN A 22.214.171.124
Here’s what these answers mean:
- 3551: This is the Time to Live (TTL), a 32-bit signed integer that holds the time interval for which a record can be cached. When it expires, the data must be used in an answer to a request until it’s been refreshed by the DNS server.
- IN: We made an Internet class query.
- A: We asked for an A record from the DNS server.
Statistics is the final section, and it contains the following information:
;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Sun Mar 22 07:44:37 EDT 2020 ;; MSG SIZE rcvd: 106
Here’s what we’ve got:
- Query Time: 0 msec: The time it took to get the response.
- SERVER: 127.0.0.53#53(127.0.0.53): The IP Address and port number of the DNS server that responded. In this case, it’s pointing to the local caching stub resolver. This forwards DNS requests to whichever upstream DNS servers are configured. On the Manajro test computer, the address listed here was 126.96.36.199#53, which is Google’s public DNS service.
- WHEN: Sun Mar 22 07:44:37 EDT 2020: When the request was made.
- MSG SIZE rcvd: 106: The size of the message received from the DNS server.
You don’t have to settle for the two extremes of tight-lipped and garrulous. The
dig command allows you to selectively include or exclude sections from the results.
The following query options will remove that section from the results:
- +nocomments: Don’t show comment lines.
- +noauthority: Don’t show the authority section.
- +noadditional: Don’t show the additional section.
- +nostats: Don’t show the stats section.
- +noanswer: Don’t show the answer section.
- +noall: Don’t show anything!
+noall query option is usually combined with one of those above to include a section in the results. So, instead of typing a long string of query options to turn off multiple sections, you can use
+noall to turn them all off.
You can then use the following inclusive query options to turn those you want to see back on:
- +comments: Show comment lines.
- +authority: Show the authority section.
- +additional: Show the additional section.
- +stats: Show the stats section.
- +answer: Show the answer section.
- +all: Show everything.
We type the following to make a request and exclude the comment lines:
dig howtogeek.com +nocomments
If we use the
+noall query option on its own, as shown below, we won’t get any useful output:
dig howtogeek.com +noall
We can selectively add the sections we want to see. To add the answer section, we type the following:
dig howtogeek.com +noall +answer
If we type the following to turn on
+stats, we’ll also see the statistics section:
dig howtogeek.com +noall +answer +stats
+noall +answer combination is used often. You can add other sections to the command line as required. If you want to avoid typing
+noall +answer on the command line every time you use
dig, you can put them in a configuration file called “.digrc.” It’s located in your home directory.
We type the following to create one with
echo "+noall +answer" > $HOME/.digrc
We can then type the following to check its contents:
Those two options will now be applied to all future uses of
dig, as shown below:
dig configuration file will be in use for the remaining examples in this article.
The information returned to your
dig requests is pulled from different types of records held on the DNS server. Unless we ask for something different,
dig queries the A (address) record. The following are the types of records commonly used with
- A Record: Links the domain to an IP version 4 address.
- MX Record: Mail exchange records direct emails sent to domains to the correct mail server.
- NS Record: Name server records delegate a domain (or subdomain) to a set of DNS servers.
- TXT Record: Text records store text-based information regarding the domain. Typically, they might be used to suppress spoofed or forged email.
- SOA Record: Start of authority records can hold a lot of information about the domain. Here, you can find the primary name server, the responsible party, a timestamp for changes, the frequency of zone refreshes, and a series of time limits for retries and abandons.
- TTL: Time to live is a setting for each DNS record that specifies how long a DNS precursor server is allowed to cache each DNS query. When that time expires, the data must be refreshed for subsequent requests.
- ANY: This tells
digto return every type of DNS record it can.
Specifying the A record type doesn’t change the default action, which is to query the address record and obtain the IP address, as shown below:
dig redhat.com A
To query the mail exchange records, we use the following MX flag:
dig yahoo.com MX
The name server flag returns the following name of the root name servers associated with the top-level domain:
dig fedora.com NS
To query the start of authority record, we type the following SOA flag:
dig manjaro.com SOA
The TTL flag will show us the time to live for the data in the DNS server’s cache. If we make a series of requests, we see the time to live reduce to nothing, and then jump back to its starting value.
We type the following:
dig usa.gov TTL
To see the text records, we type the TX flag:
dig usa.gov TXT
Specifying the DNS Server
If you want to use a particular DNS server for your request, you can use the at sign (
@) to pass it to
dig as a command-line parameter.
With the default DNS server (see below),
dig references the local caching stub resolver at 127.0.0.53.
dig usa.gov +stats
Now, we type the following to use Google’s public DNS server at 188.8.131.52:
dig @184.108.40.206 usa.gov +stats
Using dig with Multiple Domains
We can pass multiple domains to
dig on the command line, as shown below:
dig ubuntu.org fedora.org manjaro.com
If you regularly check a set of domains, you can store them in a text file and pass it to
dig. All the domains in the file will be checked in turn.
Our file is called “domains.txt.” We’ll use
cat to show its contents, and then pass it to
dig with the
-f (file) option. We type the following:
dig -f domains.txt
Reverse DNS Lookups
If you have an IP address and want to know where it goes, you can try a reverse DNS lookup. If it resolves to a server registered with a DNS server, you might be able to find out its domain.
Whether you can depends on the presence of a PTR (pointer record). PTRs resolve an IP address to a fully qualified domain name. However, because these aren’t mandatory, they’re not always present on a domain.
Let’s see if we can find out where the IP address 220.127.116.11 takes us. We type the following, using the
-x (reverse lookup) option:
dig -x 18.104.22.168
Presto! The IP address resolves to gnu.org.
Because a PTR is a DNS record, and we know
dig can request specified DNS records, couldn’t we just ask
dig to retrieve the PTR for us? Yes, we can, but it does take a bit more work.
We have to provide the IP address in reverse order and tack
.in-addr.arpa on the end, as shown below:
dig ptr 22.214.171.124.in-addr.arpa
We get the same result; it just took a bit more effort.
Can You dig It?
We all use the internet daily, and inquisitive minds have often wondered how the magic happens when we type the name of a website into a browser. With
dig, you can explore the processes of network conjuring.