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….

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:

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

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.

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:

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:

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 “ . “

By simply typing in:

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

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

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.

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:

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

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.

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:

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:

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.

Related posts:

A good friend sent me a link to a 90-minute video on becoming super productive that essentially boils down to this: focus only on the things that matter and stop doing the million other things that…

100 Doors is a 3D point-and-click room escape game with interactive elements and puzzles that sets in a big school building. Release Date December 2018 (Android) April 2019 (iOS) February 2021…

I get a lot of questions about SEO. For example, Why SEO is essential for the business? Why is SEO necessary for small businesses? Is SEO important for the website? Why is SEO important for online…