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.

Installing dig

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:

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:

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 less:

The output is displayed in less, as shown below.

Here’s the full listing:

Let’s dissect that piece by piece.

First, let’s take a look at we have in the Header:

Now, here’s what all of that means:

First line: The version of dig and the domain that was queried. Global options: As we’ll see, you can use dig to 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 +cmd (command) option. Opcode: Query: This is the type of operation that was requested which, in this case, was a query. This value can also be iquery for an inverse query, or status if 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 query, 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. )

Opt Pseudosection

Next, we see the following in the Opt Pseudosection:

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.

Question Section

In the Question section, we see the following:

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, dig will request an A (address) record from the DNS server.

Answer Section

The Answer section contains the following four answers we received from the DNS server:

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 Section

Statistics is the final section, and it contains the following information:

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 8. 8. 8. 8#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.

Being Selective

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!

The +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:

If we use the +noall query option on its own, as shown below, we won’t get any useful output:

We can selectively add the sections we want to see. To add the answer section, we type the following:

If we type the following to turn on +stats, we’ll also see the statistics section:

The +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:

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:

This dig configuration file will be in use for the remaining examples in this article.

DNS Records

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 dig:

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 dig to 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:

To query the mail exchange records, we use the following MX flag:

The name server flag returns the following name of the root name servers associated with the top-level domain:

To query the start of authority record, we type the following SOA flag:

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:

To see the text records, we type the TX flag:

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.

Now, we type the following to use Google’s public DNS server at 8.8.8.8:

Using dig with Multiple Domains

We can pass multiple domains to dig on the command line, as shown below:

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:

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 209.51.188.148 takes us. We type the following, using the -x (reverse lookup) option:

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:

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.