How to use the dig Command on Linux

A stylized terminal window on a Linux system.Fatmawati Achmad Zaenuri / Shutterstock

The Linux dig command allows you to query DNS servers and perform DNS lookups. You can also find the domain that an IP address leads to. We will show you how!

How the dig command works

People use Linux dig command to query Domain Name System (DNS) waiters. digging is an acronym for Groper Information Domain. With dig, you can query DNS servers for information on various DNS records, including host addresses, email exchanges, name servers, and related information. It was to be a diagnostic tool for DNS problems. However, you can use it to poke around and find out more about DNS, which is one of the central systems that keep Internet routing traffic.

Internet uses Internet Protocol (IP) addresses to identify “locations” on the web, but people use domain names. When you enter a domain name in an application, such as a web browser or SSH client, something must be translated 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 a program connected to the Internet, your local router cannot resolve it (unless it is cached from a previous request). Therefore, your router queries the DNS server of your Internet service provider (ISP) or any other server that you have configured to use. These are called DNS precursor servers.

If the DNS server recently received the same request from another person on the same computer, the response may be in its cache. If so, it simply returns the same information to your program.

If the DNS precursor server cannot locate the domain in its cache, it contacts a DNS root name server. A root server will not contain the information necessary to resolve domain names to IP addresses, but it will contain lists of servers that can respond to your request.

The root server looks at the top level domain to which your domain name belongs, such as .COM, .ORG, .CO.UK, etc. It then sends a list of top-level domain servers that manage these types of domains to the DNS precursor server. The precursor DNS server can then send its request again to a top-level domain server.

The top-level domain server sends the details of the authoritative name server (where the domain details are stored) on the precursor DNS server. The DNS server then queries the authoritative name server that hosts the domain zone that you originally entered in your program. The authoritative name server returns the IP address to the DNS server, which in turn returns it to you.

Digging facility

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

First steps with dig

In our first example, we will 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 answer:

dig howtogeek.com + short

All IP addresses associated with the domain howtogeek.com 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 make it pass less:

dig howtogeek.com | Less

The output is displayed minus, as shown below.

Here is the complete list:

; <> DiG 9.11.3-1ubuntu1.11-Ubuntu <> howtogeek.com
;; global options: + cmd
;; I have an answer:
;; – >> HEADER << – opcode: QUERY, status: NOERROR, id: 12017
;; flags: qr rd ra; REQUEST: 1, RESPONSE: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
; howtogeek.com. IN ONE

;; RESPONSE SECTION:
howtogeek.com. 3551 IN A 151.101.194.217
howtogeek.com. 3551 IN A 151.101.130.217
howtogeek.com. 3551 IN A 151.101.66.217
howtogeek.com. 3551 IN A 151.101.2.217

;; Request time: 0 msec
;; SERVER: 127.0.0.53 # 53 (127.0.0.53)
;; WHEN: Sun 22 March 07:44:37 EDT 2020
;; MSG SIZE rcvd: 106

Let’s break it down piece by piece.

On your mind

Let’s first see what we have in the header:

; <> DiG 9.11.3-1ubuntu1.11-Ubuntu <> howtogeek.com
;; global options: + cmd
;; I have an answer:
;; – >> HEADER << – opcode: QUERY, status: NOERROR, id: 12017
;; flags: qr rd ra; REQUEST: 1, RESPONSE: 4, AUTHORITY: 0, ADDITIONAL: 1

Now here’s what it all means:

First line: The version of dig and the domain questioned.
Global options: As we will see, you can use dig to query multiple domains simultaneously. This line shows the options that have been applied to all domain requests. In our simple example, it was just the default + cmd (command) option.
Opcode: Request: This is the type of operation requested which, in this case, was a request. This value can also be an iquery for a reverse query or a status if you are simply testing the state of the DNS.
Status: No error: There were no errors and the request was successfully resolved.
ID: 12017: This random ID links the request and response together.
Flags: qr rd ra: These represent the request, the desired recursion and the available recursion. Recursion is a form of DNS lookup (the other is iterative). You can also see AA, which stands for authoritative response, which means that an authoritative name server provided the response.
Request: 1: The number of requests in this session, which was one.
Answer: 4: The number of responses in this response, which is four.
Authority: 0: The number of responses from an authoritative name server, which in this case was zero. The response was returned from the cache of a DNS precursor server. There will be no authoritative sections in the response.
Additional: 1: There is an additional piece of information. (Strangely, nothing is listed unless this value is two or more.)

Opt Pseudosection

Then we see the following in the Opt pseudosection:

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

Let’s break it down:

EDNS: version 0: The version of Extension system for DNS which is used. EDNS transmits extended data and flags by increasing the size of the User datagram protocol (UDP) packets. This is indicated by a variable size indicator.
flags: No indicator is used.
udp: 4096: The size of the UDP packet.

Questions section

In the Question section, we see the following:

;; QUESTION SECTION:
; howtogeek.com. IN ONE

Here’s what it means:

howtogeek.com: The domain name we are looking for.
IN: We are making an Internet class request.
A: Unless otherwise noted, dig will request an A (address) record from the DNS server.

Answers section

The Response section contains the following four responses we received from the DNS server:

howtogeek.com. 3551 IN A 151.101.194.217
howtogeek.com. 3551 IN A 151.101.130.217
howtogeek.com. 3551 IN A 151.101.66.217
howtogeek.com. 3551 IN A 151.101.2.217

Here’s what these answers mean:

3551: This is Time to Live (TTL), a 32-bit signed integer that contains the time interval during which a record can be cached. When it expires, the data must be used in a response to a request until it is updated by the DNS server.
IN: We made an Internet class request.
A: We requested an A record from the DNS server.

Statistics section

Statistics is the last section and contains the following information:

;; Request time: 0 msec
;; SERVER: 127.0.0.53 # 53 (127.0.0.53)
;; WHEN: Sun 22 March 07:44:37 EDT 2020
;; MSG SIZE rcvd: 106

Here’s what we have:

Request time: 0 ms: The time it took to get the answer.
SERVER: 127.0.0.53 # 53 (127.0.0.53): The IP address and port number of the responding DNS server. In this case, it points to the local caching stub resolver. This forwards DNS queries to the configured upstream DNS servers. On the Manajro test computer, the address given here was 8.8.8.8 # 53, which is Google’s public DNS service.
WHEN: Sun 22 March 07:44:37 EDT 2020: When the request has been made.
MSG SIZE rcvd: 106: The size of the message received from the DNS server.

Be selective

You don’t have to settle for the two extremes of tight, chatty lips. The dig command allows you to selectively include or exclude sections of the results.

The following query options will remove this section from the results:

+ nocomments: Do not display comment lines.
+ absence of authority: Do not display the Authority section.
+ noadditional: Do not display the additional section.
+ nostats: Does not display the statistics section.
+ noanswer: Do not display the response section.
+ noall: Don’t show anything!

The + noall query option is usually combined with one of the above to include a section in the results. So instead of typing a long string of query options to disable multiple sections, you can use + noall to disable all of them.

You can then use the following inclusive query options to re-enable the ones you want to see:

+ comments: Display comment lines.
+ authority: Show the authority section.
+ additional: Display the additional section.
+ statistics: Display the statistics section.
+ answer: Display the response 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 alone, as shown below, we will not 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 activate + stats, we will also see the statistics section:

dig howtogeek.com + noall + answer + stats

The combination + noall + answer is often used. You can add other sections to the command line as needed. 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 is in your personal directory.

We type the following to create one with echo:

echo “+ noall + answer”> $ HOME / .digrc

We can then type the following to check its content:

cat .digrc

$ HOME / .digrc “and” cat .digrc “commands in a terminal window.” width = “646” height = “122” onload = “pagespeed.lazyLoadImages.loadIfVisibleAndMaybeBeacon (this);” onerror = “this.onerror = null; pagespeed.lazyLoadImages.loadIfVisibleAndMaybeBeacon (this);” />

These two options will now be applied to all future uses of digging, as shown below:

dig ubuntu.org
dig linux.org
dig github.com

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

DNS records

The information returned to your search requests comes from different types of records kept on the DNS server. Unless we ask for something different, digging queries record A (address). Here are the types of records commonly used with dig:

A recording: Bind the domain to a version 4 IP address.
MX record: The email exchange records direct emails sent to domains to the appropriate email server.
NS record: Name server records delegate a domain (or subdomain) to a set of DNS servers.
TXT record: Text records store text information about the domain. Typically, they can be used to delete spoofed or spoofed emails.
SOA registration: The start of authority records can contain a lot of information about the field. Here you can find the main name server, the responsible party, a timestamp for changes, the frequency of zone refreshes and a series of delays for attempts and abortions.
TTL: Lifespan is a setting for each DNS record that specifies how long a DNS precursor server is allowed to cache each DNS request. At the end of this period, the data must be updated for the following requests.
ALL: This tells dig to return all types of DNS records it can.

Specifying the A record type does not change the default action, which is to query the address record and get 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 the 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 cache. If we make a series of requests, we see the time to live reducing to nothing, then returning to its initial value.

We type the following:

dig usa.gov TTL

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

dig usa.gov TXT

DNS server specification

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 refers to 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 8.8.8.8:

dig @ 8.8.8.8 usa.gov + stats

Using Dig with multiple domains

We can pass multiple areas 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 send it to dig. All areas of the file will be checked in turn.

Our file is called “domains.txt”. We will use cat to display its contents, then we will pass it to dig with the option -f (file). We type the following:

cat domains.txt
dig -f domains.txt

Reverse DNS lookups

If you have an IP address and want to know where it is going, you can try a reverse DNS lookup. If it resolves to a server registered with a DNS server, you may be able to discover its domain.

Your ability depends on the presence of a PTR (pointer record). PTRs resolve an IP address into a fully qualified domain name. However, since these are not mandatory, they are 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 option (reverse search):

dig -x 209.51.188.148

Presto! The IP address is resolved in gnu.org.

Because a PTR is a DNS record, and we know that digging can ask for specified DNS records, couldn’t we just ask to dig to retrieve the PTR for us? Yes, we can, but it takes a little more work.

We need to provide the IP address in reverse order and nail .in-addr.arpa at the end, as shown below:

dig ptr 148.188.51.209.in-addr.arpa

We get the same result; it just took a little more effort.

Can you dig it?

We all use the Internet daily, and curious minds have often wondered how the magic happens when we type the name of a website in a browser. With Digging, you can explore the processes of network conspiracy.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.