Mark Minasi's Windows Networking Tech Page
Issue #94 Late November 2011

Document copyright 2011 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text.

What's Inside

• News
  • Learn with My Seminars, Audio Recordings and More!
• Tech Section
  • Getting and Using DIG, a Great DNS Troubleshooter That Runs Rings Around NSLOOKUP
• Conferences
• To Subscribe, Unsubscribe, Read Old Newsletters or Change Your Email Address

News

Hi all —

Just about anybody who’s maintained networks for any time at all knows that when DNS stops working, so does just about everything else, and that's why most of us network troubleshooter types spend at least some time in every work year troubleshooting DNS. Furthermore, anyone who's ever tried to troubleshoot anything knows that trying to fix things with lousy tools takes longer and is more frustrating than trying to fix it with good tools... which is why it's so sad that the main troubleshooting tool built into Windows is nslookup.  A fairly lame tool, nslookup isn't smart enough to use your alternate DNS server when your preferred DNS server is offline, is completely DNSSEC-dumb, and offers you essentially nothing in the way of useful packet-level information, to name just a few of its sins.  If only there were a better tool... but aha, there is... and thereby hangs this tale.  Before I can tell that tale, however, a word from our sponsor...

Getting and Using DIG, a Great DNS Troubleshooter That Runs Rings Around NSLOOKUP

For years, I’d always heard of a much more powerful DNS troubleshooting tool called DIG that the Unix folks used while looking down their noses and snickering at we poor Windows admin fools.  (It's spelled like that because "DIG" stands for Domain Internet Groper."  Don't ask.) The tales claimed that DIG made nslookup look pathetic and that Microsoft was going to include DIG in Windows Server 2003, which never happened, and then that it was to appear in Windows Server 2008, which never happened, and then in Windows Server 2008 R2, and, well, you see where this was going.  So in early 2009, I thought it was just about time to see if I couldn't find a version of DIG that ran on Windows so that I could try it out for myself. 

Here's what I found, and how to get started with DIG.  (In case you haven't guessed, it's pretty neat.)

Getting DIG

You can't play with DIG until you get a copy of it, so here's where to find it, and by the way, it's free.  DIG is part of the BIND suite of software, which is a free DNS server whose source code is hosted at isc.org.  (The chances are good that most of you know this already, but forgive me for filling in to those who don't know it that BIND is by far the most popular DNS server software around, and comes both in Unix and Windows flavors.  I did mention that it's free, right?)  Our interest in the BIND software is not, however, to run a BIND server (although we could, even on an XP box) but instead to download the BIND software files and pick out just the files we need for DIG. Here's what to do.

1. Go to www.isc.org/downloads.
2. Look down the page a bit and locate the latest production version.  As I write this, it's BIND 9.8.1-P1, but they update it regularly, so you may see a newer one.  Look just below that for the hyperlink that says "Windows Download."  Click on that and you'll be able to download a ZIP file.
3. Create a folder to receive the BIND files.  I created and used a folder named C:\DIG, but you can use any folder name.
4. Put that folder on your system's path.  If you haven't updated a path in a while, look (on Windows 7 and R2) in Control Panel / System and Security / Security / Advanced system settings / Environmental Variables, then under "System variables," find "PATH,"click "edit..." and, in the resulting dialog box, go the end of the current PATH string, type a semicolon and then the name of the folder that you just created, and then click OK.
5. Copy the BIND files to the folder that you just created. (C:\DIG in my example.)
6. Delete all but the following files:
   • DIG.exe
   • DIG.html
   • lib*.dll (there will be eight of them in the latest version)
   • vcredist_x86.exe
7. Run vcredist_x86.exe -- if you don't, you'll get an error about how DIG can't run because of a side-by-side error.

Your First DIG

Next, let's try it out by resolving the address for my Web site, www.minasi.com.  The DNS address of my Web server is a tiny bit tricky as there aren't actually any machines on the web exactly named "www.minasi.com," just a machine with the name "web2.minasi.com" to which I've added a second name of www.minasi.com.   (For those who haven't messed with DNS recently, recall that DNS calls any extra names that you give to a machine not its "host name" but instead "aliases" or "canonical names."  Remember also that DNS abbreviates "canonical name" as CNAME, which is usually written in all caps.)

To try DIG out, just open a new command prompt window (so it's got the new path), and just type

DIG www.minasi.com

And, so long as you've followed the above steps, you'll see some output like this:

C:\>DIG www.minasi.com

; <<>> DIG 9.7.3-P1 <<>> www.minasi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21888
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 0

;; QUESTION SECTION:
;www.minasi.com. IN A

;; ANSWER SECTION:
www.minasi.com. 3600 IN CNAME web2.minasi.com.
web2.minasi.com. 3600 IN A 70.165.73.5

;; AUTHORITY SECTION:
minasi.com. 163676 IN NS netdoor.minasi.com.
minasi.com. 163676 IN NS web2.minasi.com.

;; Query time: 140 msec
;; SERVER: 24.178.162.3#53(24.178.162.3)
;; WHEN: Mon Jun 06 18:32:33 2011
;; MSG SIZE rcvd: 122

Yes, that's a lot of output, much of it fairly ugly, and I will explain it in this and future newsletters, but as you'll soon see, it's largely useful ugly output.  If, however, you want "just the facts, ma'am," then add the optional value "+short," as in this output:

C:\>DIG www.minasi.com +short
web2.minasi.com.
70.165.73.5

I know that some of you are thinking, "hey, I want that '+short' option to be the default all the time, how do I do that?," and fortunately I have some good news.  The DIG documentation says that you should be able to create a text file called "DIGrc" and fill it with any desired options and then place that in your home directory, and afterwards DIG will read and use those options.  It doesn't exactly work that way, but it does work.  Here's how you'd tell your copy of DIG to always use the +short option (and any others you like):

• Create a file called ".digrc" and notice that it starts with a period and does not have an extension.  Just to keep track of things, I put it in the same folder as I've got the DIG files which was, recall, C:\DIG.
• Edit it as you'd edit any text file -- Notepad works fine -- and put an options on a line by themselves.  To try it out, just put "+short" on a line by itself in .digrc.
• Tell DIG where to find .digrc by creating another environment variable, "home," and point it to the folder containing .digrc, as in "set home=c:\dig" to point it (obviously) to the C:\DIG folder.

Run "dig www.minasi.com" again, and you'll see output as if you'd used +short.  (My thanks to reader Ed Plate, who straightened me out on how to use digrc on Windows systems.)

Oh, and hey, just for comparison's sake and comic relief, let me include nslookup's output:

C:\>nslookup www.minasi.com
Server: vip01spbgsc.spbg.sc.charter.com
Address: 24.178.162.3

Non-authoritative answer:
Name: www.minasi.com.minasi.com
Addresses: 184.106.31.166
204.232.162.92

Nope, I didn't fake that and in truth most of the blame for that ridiculous result must be laid at the feet of some nimrod at my ISP who configured their DNS server, but their misconfiguration didn't confuse DIG ... just poor dumb nslookup.

Reading DIG Output: What to Watch, What to Ignore (for Now)

Yes, the output from the DIG command is a mite scary at first, as it has the Unix-y air of "if you don't immediately understand this, you're probably not meant to be using this tool and you probably don't even have a ponytail like all good Unix administrators do," but I promise, it won't be all that bad once we've picked it apart, which we're about to do.  I will dissect all of the output in future newsletters -- trust me, to know DIG is to love it -- but for now, here are the high points to look for:

• Two items, "got answer" and "status: NOERROR," that tell you that the mission was accomplished.
• The answer to your question, which was after all the point of the command.
• The server that got you the answer.

Here's where to find those things on a DIG output of a more interesting DNS lookup, for www.microsoft.com:

Fairly high up on the DIG output, we see the first bit of good news, "Got answer" instead of something like "connection timed out; no servers could be reached."  Thus, if we were to query DIG for information about some nonexistent domain like www.aslfkheoiwfh.com and DIG found a working DNS server that said, "nope, there's no domain like that," then we'd still get the response of "Got answer."

The second bit of useful information is "status: NOERROR," which means pretty much what it says.  If I'd queried for a DNS record that didn't exist like the www.aslfkheoiwfh.com example I cited before, then again I'd see a "Got answer" but the status would be "NXDOMAIN" which means "nonexistent domain."  (Yes, www.whatever is an A record, not a domain, but that's the name of the error that the low-level DNS protocol specifies when you ask for pretty much anything that doesn't exist, and DIG's output cleaves close to the the low-level DNS output.)

Third, there's the answer to your question, which appears in something called the "answer section," which seems, well, kind of well-named.  It offers three aliases -- CNAMEs -- chained together, as the actual answer to "what's the IP address associated with www.microsoft.com?" is apparently not a simple one, as

• Looking up "www.microsoft.com" yields the answer that it's actually an alias for toggle.www.ms.akadns.net
• Looking up toggle.www.ms.akadns.net yields the answer that it is actually an alias for g.www.ms.akadns.net
• Looking up g.www.ms.akadns.net reveals that it is an alias for yet another name, lb1.www.ms.akadns.net
• Finally, looking up lb1.www.ms.akadns.net returns that is (finally) not an alias but instead a true "A" (address) record, pointing to 207.46.131.43.

Lastly, "SERVER: 10.50.50.4#53..." shows that the DNS server that answered DIG's request lives at that IP address.  The "#53" means that DIG communicated with that DNS server on the server's port number 53, the standard DNS port.

DIG knew to query that DNS server because, again by default DIG sends any DNS requests to your computer's preferred DNS server first, then its first alternate DNS server (if any), then the second alternate (if any), and so on.  As I've mentioned before, that's one way that DIG's more useful than nslookup.  Nslookup just tries your preferred DNS server and if that one's not available, nslookup just gives up.  Once, a friend called me up in a panic, explaining that he'd configured two DNS servers for his company -- call them dns1.bigfirm.com and dns2.bigfirm.com -- and that he'd set up DHCP to make dns1.bigfirm.com everyone's preferred DNS server and dns2.bigfirm.com everyone's alternate DNS server.  He then explained that "at that point, everything was working fine, but I wanted to be sure that I'd set up DNS right, so I shut down dns1.bigfirm.com and tried looking up the IP address of www.google.com ... and it failed.  Why isn't my workstation knowing to use dns2.bigfirm.com?"  I thought about it for a moment and asked him how he'd looked up the Google IP address, and by now you've guessed that he used nslookup.  Had he merely fired up a copy of Internet Explorer and pointed it at www.google.com, then IE -- which is built atop Windows components that are smarter than nslookup's -- would have seen that the preferred DNS server wasn't available and would have seamlessly moved to the alternate DNS server.

Specifying a Different DNS Server

There's much more that you can do with DIG than just simple lookups like "DIG www.microsoft.com."  A more general description of its syntax looks like

DIG [@dns-server-to-use] record-to-look-up [type-of-record-to-look-up] [options]

And in case you've forgotten your Backus-Naur formats, the stuff in square brackets is optional.  As you've already read, you don't have to tell DIG what DNS server to send its queries to, as it uses the ones you got from DHCP or that someone statically assigned.  But if you wanted to tell DIG to do that microsoft.com query on a particular server, like my DNS server at 70.165.73.5, then you'd override its choice of DNS servers by specifying that server prefixed by an "@," like this:

 DIG www.microsoft.com @70.165.73.5

DIG doesn't care about the order of the "@server" and the query, and so this syntax works just as well:

DIG @70.165.73.5 www.microsoft.com

In the unlikely event that your DNS server doesn't receive requests on the standard port 53, you can tell DIG to query the DNS server on an alternate port with the -p option.  So if my DNS server listened on port 60 -- it doesn't -- then you could query it like this:

DIG -p 60 www.microsoft.com @70.165.73.5

Of course, this would work:

DIG -p 53 www.microsoft.com @70.165.73.5

As before, you can rearrange the -p 53, the www.microsoft.com, and the @70.165.73.5 in any order that you like.  I use the @server option now and then when I need to test changes I've made to my DNS servers from the point of view of an outside visitor.  For example, I recently decommissioned one of the minasi.com DNS servers.  As I run those servers, any workstations that I sit down at will use the actual authoritative minasi.com DNS servers as their preferred DNS server, which means that any sort of name resolution tests on changes to minasi.com are always going to work, even if I've screwed up something over on the .com DNS servers.  In that case, I should try to resolve www.minasi.com for test purposes, but to do that, I've got to run the tests from a DNS server outside of my network, and the @server feature lets me do that easily.  (By the way, nslookup lets you do this as well by following the query with the name or IP address of the desired DNS server, as in "nslookup www.minasi.com 70.165.73.5" -- again, the order doesn't matter.)

Telling DIG to Query a Particular Record Type

Most of the time, we're looking for an address ("A") record, the type that reports the IP address corresponding to a particular host name.  But sometimes we want to find MX, SOA, CNAME or the like records.  In that case, type the desired record type after the record you're querying.  For example, the following two queries return the SOA record and then the MX records for minasi.com:

DIG minasi.com SOA

DIG minasi.com MX

Getting More DIG Help

Normally you'd expect a command-line tool to return help if you typed something like "DIG /?," "DIG -?" or something of the like, but DIG wants -h as in

DIG -h

I hope that'll get you a good start in using and understanding DIG.  I'll cover more DIG in the next newsletter... see you then!

Upcoming Conferences

If you can't make it to a Server 2012, Windows 8 or PowerShell seminar, perhaps I'll see you at...

TechMentor Vegas

TechMentor returns to Las Vegas this September 30-October 4 and I'll be doing a bunch of talks, so don't miss it!  Find out more at http://techmentorevents.com/Home.aspx.

TechEd

I'll be at TechEd North America and TE Europe this year doing a talk on Server 2012 networking and Windows 8 goodies, if you'll be at either show please stop by!

To Subscribe/Unsubscribe, Read Old Newsletters or Change Your Email Address

To subscribe, visit http://www.minasi.com/nwsreg.htm. To change e-mail or other info, link to http://www.minasi.com/edit-newsletter-record.htm.  To unsubscribe, link to http://www.minasi.com/unsubs.htm. Visit the Archives at http://www.minasi.com/archive.htm. Please do not reply to this mail; for comments, please link to http://www.minasi.com/gethelp.

All contents copyright 2011 Mark Minasi.  I encourage you to quote this material, SO LONG as you include this entire document; thanks.