There’s little debate that one of the absolutely fundamental services critical to the functionality of the Internet is the Domain Name System (DNS). Akin to the Simple Mail Transfer Protocol (SMTP), which is the grounding for all things email, and the Network Time Protocol (NTP), which keeps the Internet ticking, DNS has unquestionably played a key part in both the Internet’s inception and somewhat surprisingly its continued growth — a testament to its architects.
During the course of administering online systems effectively, sysadmins need to run name servers, which include the likes of BIND and djbdns (also called TinyDNS) to answer the questions asked about the domain names for which they’re responsible. And, they use various tools to query other domain name settings hosted remotely.
Several DNS lookup tools are available in Linux. Some are bundled with operating systems in one form or another, and others are installed optionally as packages on top. If you’re like me, you tend to get used to one package in particular, which you then either explore thoroughly or use to a smaller degree alongside other packages. My long-time favorite DNS lookup tool has been the “host” command; however, there have been occasions when it didn’t quite cut the mustard and provide the level of detail required to complete a task.
In these situations, my tool of choice has been the dig command, which is a successor to the nslookup and host commands and which is bundled with the BIND name server. Of course, it’s possible the host command did in fact have some have of the features I needed, but perhaps there weren’t enough examples readily available on the Internet when I looked or they weren’t as intuitively constructed, which meant they were easily forgotten.
In this series of articles, I will explore the powerful dig utility. For those who haven’t used the command before, these articles will give a useful overview of its features and uses. And, for those that have utilized dig in the past, the articles should serve as a reminder of the tool’s versatility and extensive functionality.
Apparently, dig stands for Domain Information Groper, and who am I to suggest that its naming might have involved a backronym? For all intents and purposes, the functionality of DNS is simply the act of converting an IP address to a domain name and the reverse, converting a domain name to an IP address. I use the words “domain name” advisedly and, more accurately, I really mean a hostname (e.g., “mail.chrisbinnie.tld” or “www.chrisbinnie.tld”).
Wherefore Art Thou?
Incidentally, if you can’t get a response from typing dig on your command line then you might not be lucky enough to have it installed. On Debian and Ubuntu, you can install the dnsutils package by typing:
# apt-get install dnsutils
On Red Hat and CentOS systems, you can install it with the following command:
# yum install bind-tools
For future reference, if you are unsure which package an already installed file belongs to on Red Hat-based systems, then you might want to try this command:
# rpm - qf /usr/bin/dig
On Debian-based systems, the same can be accomplished using the faithful dpkg package manager as follows:
# dpkg --search /usr/bin/dig
However, without the packages installed already, the following commands may do the trick if you need to look for a file. Be warned that, depending on software versions, your mileage may indeed vary:
# yum whatprovides '*bin/dig' # apt-cache search dig dns
Baby Steps
Let’s take a moment now to explore the basics of dig using a few of the more straightforward command-line options.
Note that on most Unix-like systems, the lookup order of which name servers to query can be found inside the file /etc/resolv.conf, which might have contents similar to this:
nameserver 8.8.8.8 nameserver 208.67.222.222
The other options, instead of just using “nameserver” within that file, are using short names relative to the local domain for that server. Therefore, another option for /etc/resolv.conf might simply be:
domain chrisbinnie.tld
Using that “domain” option, should we simply look up mail — without the full domain name appended to it — then our query would automatically resolve to mail.chrisbinnie.tld. In other words, this is the system’s local domain name.
Another option is the search parameter, which you can also use for resolving shortened hostnames. If, for example, you use two domain names frequently, then adding the following entries will check each in the same way as the “domain” option allows. An example might be:
search chrisbinnie.tld binnie-linux.tld
Heads Up
Now that you can see how the operating system performs its DNS lookups, let’s look at some of dig’s features as promised.
The host command typically responds to time-honored syntax as follows to look up MX records for a Domain Name:
# host -t mx chrisbinnie.tld
The DNS tool nslookup, however, can drop you down into what might be described as its own command-line interface having executed its name from your own command line, although it does let you enter commands directly into the command line, too.
You might use the nslookup command directly, as shown in following example. This functionality can also be achieved with the same syntax using the host command. You can directly query a specific name server for its response (instead of relying on other DNS lookups to get you to that server in the first place) to get a definitive answer with a command such as:
# nslookup mail.chrisbinnie.tld 8.8.4.4
Conversely, you might perform a reverse DNS lookup using the following in order to convert an IP address to a domain name:
# nslookup 192.168.0.1 8.8.4.4
In both cases, “8.8.4.4” is the IP address of a popular DNS resolver that will ask other name servers for the answer should it not be armed with it.
I mention the syntax of other DNS tools because the mighty dig utility, in its wisdom, does things slightly differently. A typical query might look something like this:
# dig @8.8.4.4 chrisbinnie.tld mx
Appended to the @ sign is the name of the server that we wish to directly query. Then, the “chrisbinnie.tld” element is the resource that we are asking that name server about. Finally, the last entry on the command line is the type of query, which might be any, mx, or a records, for example.
This Vehicle Is Reversing
If we use the easy-to-remember -x switch, then it’s possible to always force a reverse DNS lookup where you convert an IP address to a hostname. This command shows an intentionally abbreviated output for clarity:
# dig -x 193.0.6.139 139.6.0.193.in-addr.arpa. 21600 IN PTR www.ripe.net.
Next time, I’ll look more closely at the dig syntax, which, again, is a little different from other DNS lookup packages, and I’ll explain more of its many features.
Read Part 2 of this series.
Chris Binnie is a Technical Consultant with 20 years of Linux experience and a writer for Linux Magazine and Admin Magazine. His new book Linux Server Security: Hack and Defend teaches you how to launch sophisticated attacks, make your servers invisible and crack complex passwords.
Advance your career in Linux System Administration! Check out the Essentials of System Administration course from The Linux Foundation.
