Can You DIG It?

As I dig deeper into Linux for the SQL Server DBAs and for Oracle HotSos, I’m digging into DIG.  Yeah, I went there with that first sentence….

What is DIG?

DIG stands for Domain Information Groper, (no, not that kind of groper…)  and it’s an important part of deeper Linux learning for all database technologists.  You can’t connect to data if you don’t know how to get from point A to point B and DIG is the utility to help you gather information surrounding DNS.  DIG allows the user to gather deep information using both command line arguments and batch mode with a list file, so it can be used as part of scripts and alerting.  DIG has a lot of functionality, more so than I found with nslookup and I’m surprised at how little its mentioned for use by DBAs as often as the type of information could assist when we’re troubleshooting.

First, let’s discuss the help option for DIG.  Your first inclination is to type:

$ dig --help

but, even the –help option will recommend, use the following for a more complete set of help information:

$ dig --h

I know it’s a small change, but the output is well worth it.

DIG is used with a combination of arguments using letters after a hyphen and a plus sign followed by a command word.

$ dig -<x> +<command>

Sourcing

By default, DIG will search the /etc/resolv.conf file for names servers and will only deviate from this when instructed to.

I’m on a docker container, which is a perfect place to get acclimated to DIG, so my file is pretty simple:

$ view /etc/resolv.conf

# Generated by dhcpcd from eth0.dhcp
# /etc/resolv.conf.head can replace this line
domain <domain>.com
nameserver <IPAddy>
# /etc/resolv.conf.tail can replace this line

To change to point to another names server than listed in this file, you can add it in the argument line or you can add a .digrc file to your $HOME directory to be used with DIG.  A .digrc file is a simple text file with entries that look like the following with as many entries as required.  In the example, I’ve added delphix, but you can add as many as required:

# dig delphix.com
delphix.com.              3427    IN      A       23.185.0.3
<next.com>                3427    IN      A       <IP Address>

Starting Out

If you simply type in dig without any command line arguments, you’ll get everything returned from the root directory, (for those of you SQL Server folks still getting used to this, it’s the very top of the hierarchy tree, also known as ” . ”

We can use DIG to explore any domain and for our example, we’ll use PASS’ website, http://pass.org.

By simply typing in:

$ dig <domain name>

We receive a good amount of information.  Each line starting with a single “;” is a comment, where ones with double “;” are responses.

• It informs you what the question was, in this case, “pass.org”
• It then informs you that the next section consists of the answer, which tell you:
  • The time of the query
  • The names server used
  • The timestamp, including timezone
  • And the message size.

You can shut these statistics about the query, (time, timestamp, size) off by issuing the following updated command:

$ dig <domain name> +nostats

Now lets say we don’t need all of that information.  We just want to know the IP address for the domain we’re inspecting.  We can then use the “+short” argument, which you’ll see in the screenshot above.

Now PASS is a pretty simple, straight forward site, but what about one with a lot of front end tolerance built into it, (depending on the architecture, design, etc.)  It may return a lot more information, which using the “+short” argument, can be seen for http://ebay.com.

You can test this out yourself with different domains and see the results.  Notice the difference when you run this command, both with and without the “+short” for sites  like:

• google.com
• microsoft.com
• aws.com
• oracle.com

I can take this farther and query for all DNS records for the PASS site:

$ dig pass.org ANY +noall +answer

In other words, give me any DNS information, without all the extra data, including stats, but I do want the answers.  This is different than using the “+nostats” argument.  The results displays the IP information for the pass.org, identified by “A”, all the names servers identified by “NS” and you can see SOA, Mail Exchange, (MX) and text answers that are returned, (TXT).  You may receive other categories of information back, such as security and certificates, (CAA) and Time to Live data, (TTL) which is DNS record storage.

Dig[ging] Your Host

Many of the queries I just demonstrated will provide valuable data for hosts that you work on in your environment, too.  The concept is pretty much the same, so to perform a simple query with dig, we’ll request some simple information about my Docker Container:

$ dig <host name> name type

Now the host name can be replaced with the IP address, too.  Where this can come in handy is when you’re trying to find out if the long or short name for the host is listed in DNS.  Replacing this command with each will tell me if there are any errors that come back and the names servers that are connected to along the way.  I can also see how long it takes to connect to each and proceed on.  I’m only going to capture a small amount of what is returned, as even a simple container can show an abundance of data:

Notice that I was able to quickly grab the name of the host by performing a “uname -a”, (wanted to show that if you didn’t have the name in your prompt displayed) knowing the second value returned was the value I would need for the host name, (in my case, the container name).

Let’s say I needed to do a reverse lookup on my container.  The recommended command with DIG would be the following:

$ dig -x <container name> +short

The problem is, there is no way to reverse lookup via this container.  It’s an important aspect to know with DIG is that you may start with the “+short” argument and then drop it when you do run into an unexpected response.  As you’ll see in the screenshot below, we’ll see the full answer demonstrated that there was no answer, (ANSWER: 0) to the reverse lookup on the container.

When you’re trying to figure out why ODBC, .NET, SQLJ or other connections are failing, taking too long, the DIG utility could provide valuable data to answer questions about DNS that commonly stays invisible to the database technologist.