For years now, UNIX administrators have had access to a domain name system (DNS) testing tool called DIG, which most Windows administrators don’t even know exists. DIG is a utility designed to troubleshoot DNS servers. The troubleshooting process involves submitting queries to the DNS server through DIG and watching DIG display the results of the query. Recently, various developers have ported DIG over to Windows 2000. In this article, I’ll explain what DIG is, how to install it, and how to test a DNS Server using DIG.

Acquiring BIND DIG
If you do a Google search for a Windows version of DIG, you’ll find more than one version of this utility. For the purposes of this article, I decided to demonstrate the version of DIG that comes with BIND (Berkley Internet Name Domain). BIND is a third-party implementation of DNS provided by the Internet Software Consortium.

BIND is an open source version of DNS designed primarily for reference purposes. Don’t worry about having to switch from Windows 2000’s version of DNS to BIND in order to use DIG. You don’t actually have to install BIND to be able to use DIG. Furthermore, you don’t even have to run DIG from a server. I downloaded BIND version 9.2.1 onto a Windows XP machine and then extracted the files necessary to run DIG. DIG worked beautifully without me having to actually install BIND.

You can acquire BIND by going to the Internet Software Consortium Web site. DIG has been included with all versions of BIND since 8.2.3. However, there were some serious security issues with BIND version 8, so if you’re planning on actually installing BIND, I recommend getting version 9.

BIND 9.2.1 is a 1.28-MB self-extracting ZIP file. When the download completes, extract the BIND files and copy them into an empty directory. At this point, you can install BIND by running the BINDINSTALL.EXE file. However, since this is an article on DIG and not BIND, I’m not going to get into the topic of installing BIND.

To use DIG, create an empty directory and copy the files DIG.EXE, DIG.HTML, LIBDNS.DLL, LIBEAY32.DLL, and LIBISC.DLL into it. Be advised that this step is different from previous versions. In version 8 of BIND, the required files were DIG.EXE and LIBBIND.DLL.

Once all of the necessary files have been copied, you’re ready to run DIG. The BIND version of DIG is a command-line tool, so before you run it, you should be familiar with the command syntax. You can view the command syntax by opening a Command Prompt window, navigating to the folder that you copied the DIG files into, and entering COMMAND DIG -H. As you can see in Figure A, the syntax can be overwhelming.

Figure A
This is the help screen that’s displayed when you enter the DIG -H command.

To simplify things a bit, let’s begin by looking at the DIG command in its most simple use form. Remember that DIG’s entire purpose is to test a DNS query and report back the results. The most basic DNS queries consist of the DNS server’s IP address, the IP address or URL of the entry that you want to test, and the query type. DIG allows you to enter this information in this order.

For example, my private network has a DNS server whose IP address is 147.100.100.34. Suppose that I wanted to perform a test query against that DNS for my Web site www.brienposey.com. For such a query, I’ve already got the DNS Server address and the URL that I want to look up. All I need now is the query type. Query types can consist of A, ANY, MX, NS, SOA, HINFO, and the list goes on. To keep things simple, I’ll use the ANY query type, which will report back to me any DNS records. The actual command that I would enter is:
DIG @147.100.100.34 www.brienposey.com any

The results
Here are the results of this query.

Looking at the query results can be a bit intimidating at first, but the results are actually fairly easy to understand if you know what you’re looking at. The query results can be divided into five different sections. The first of these sections is the second line, which reads:
 ; <<>> DIG 9.2.1 <<>> @147.100.100.34 www.brienposey.com any

This line simply tells you what version of DIG is being used and what query was entered.

The second part of the query results is the third line, which reads:
 ;; global options:  printcmd

This section of the query results tells me which options have been specified. In this particular case, I am told that printcmd is being used as a global option. The reason for this is that I didn’t specify any options. If you look back to Figure A, you’ll notice that the biggest part of that extremely long help file is options. These options allow you to control the query’s output. For example, I performed a recursive query by default, but I could have used one of the options to make my query nonrecursive.

The third part of the output is the line that reads:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41

This line shows the query’s status. In this particular case, the NOERROR status indicates that the query was successful. Had the query failed, you might have seen a SERVFAIL status, which is DIG’s way of saying that the server couldn’t resolve the request.

The fourth part of the query results is the following line:
 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 19, AUTHORITY: 3, ADDITIONAL: 3

This line details a bit more statistical information about your query and its results. The QUERY: 1 portion of this line indicates that you’ve made a single query. Likewise, the ANSWER: 19 portion of the line indicates that there were a total of 19 answers to the query. The line then goes on to read AUTHORITY: 3 ADDITIONAL: 3. This indicates that in addition to the 19 answers to the query, there were three authoritative DNS entries and three additional DNS entries.

The next section of the query results begins with the ;; ANSWER SECTION line and ends at the ;;Query time: 400 msec line. The answer section describes all of the DNS records that were returned by the query. I’ll talk about this a bit more later on, but the results found in this section vary greatly depending on the type of query that you’ve performed.

The last section of the DIG report begins with the ;; Query time:400 msec line and runs for the remainder of the report. This section tells how long the query took, the IP address of the server that made the query, the IP address of the DNS Server handling the query, and the total message size.

As you can see, the DIG results are easy to understand if you take the time to break them down. However, if you’re still experiencing a case of information overload, then take heart. As you may recall, my original query used the ANY record type. If you look through the fourth column of the query results, you can see that there are lots of different record types. The query results point to A, MX, and NS Records. Therefore, if you had a really long query result like this one, you could change the query type to an individual DNS entry type, and there may be significantly fewer results.

For example, I reentered my original query substituting NS for ANY. Upon doing so, my query results looked something like this: QUERY: 1 ANSWER: 0 AUTHORITY: 1 ADDITIONAL: 0. In case you’re wondering, it is possible to do a DNS query and not list a query type. If you fail to provide DIG with a query type, DIG will perform a root level NS query.

Inclusion file
All of the techniques that I’ve shown you so far are fine for lower end environments in which a single DNS server handles all of the DNS queries. But what about larger environments with multiple DNS servers? Although it isn’t listed anywhere within the help file, there is a way of configuring DIG to use multiple DNS servers simultaneously.

If you have multiple DNS servers to test, create a text file called RESOLV.CONF in the %SYSTEMROOT%\System32\Drivers\Etc folder. You can list the IP addresses for up to three DNS servers within this file. The way that DIG works is that if you provide it with a DNS server, DIG will use the DNS server that you’ve told it to. If you don’t provide a DNS server to DIG, then DIG will search the RESOLV.CONF file for DNS servers to use.

A little more help
DIG can be as simple or as complex as you’d like for it to be. Unfortunately, space limitations prevent me from discussing every option that DIG has to offer. Fortunately, there is more help available. Earlier when I had you to copy the various DIG files to the DIG folder, one of the files that I had you to copy was DIG.HTML. This file contains a much more exhaustive listing of the various options available through DIG. You can view this file by opening it in any Web browser.