Built into the vast majority of modern operating systems is the best tool for quickly diagnosing and understanding DNS responses. I am talking, of course, about the Domain Information Groper or DIG, as we like to call it.
DIG provides a wealth of information about how a zone is configured, whether or not it’s working properly and can even be queued up with multiple queries at once. Of course, all this information is a moot point if you can’t make sense of it, which is why I put this article together.
Getting Started with DIG
Getting started with DIG is as easy as locating your terminal screen on your system.
On a Mac, hit ⌘ + Space to bring up your Spotlight search, and enter “Terminal” in the box to locate your Terminal screen. Alternatively, you can navigate to Applications → Utilities and locate it there.
For our Linux friends, the location of your terminal will vary based on the distribution you’re using, however it’s typically in a conspicuous location.
Windows users get to have a little more hands-on approach to initial setup as BIND is not part of the stock Windows kernel. This can be easily remedied by visiting isc.org and downloading the appropriate BIND package for your system - 32 or 64 bit. Once that has been installed and configured, the instructions and data output in this article will be the same as that of a Mac or Linux.
Once you’re in the terminal, you’re ready to start asking DIG for some juicy DNS details!
DIG Command Basics
Your run-of-the-mill, basic dig command will follow a format like this:
$ dig name @server type
dig invokes the utility
name is the host you are looking for information about (eg. example.com)
@server allows you to query the name from a different location (eg. 8.8.8.8 for Google's resolver or dns1.p01.nsone.net to test a zone before you delegate)
type is an optional field that allows you to have DIG locate a specific record type (eg. A, AAAA, CNAME, MX, TXT, etc.)
Example - Zone Delegation Pre-Check
Let's say I went out and registered example.com and just went and set up a shiny new zone here at NS1. All is well and good, but I want to make sure that this delegation swap is going to work before I notify my registrar of the change. I've noted my name server assignment from the NS1 Portal for example.com, and will call DIG like this:
$ dig example.com @dns1.p01.nsone.net
The following results magically flash onto the terminal screen:
; <<>> DiG 9.8.3-P1 <<>> example.com @dns1.p01.nsone.net a ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60796 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 3600 IN A 104.20.48.182 ;; Query time: 8 msec ;; SERVER: 198.51.44.1#53(198.51.44.1) ;; WHEN: Fri Jul 8 10:55:40 2016 ;; MSG SIZE rcvd: 45
Result! We can see that example.com points to 104.20.48.182 in the answer section.
A Closer Look
From the top...
; <<>> DiG 9.8.3-P1 <<>> example.com @dns1.p01.nsone.net
The first line of the DIG indicates what version of the utility is currently installed, and the query that was invoked.
;; global options: +cmd
There are a bevy of options that can be tacked onto DIG, and I will dive deeper on this later on. For now, just know that in this case, my default instance of DIG was set up to display the first line of the response.
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60796 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available
Got an answer, hooray! The first part of the answer is the header, which has been clearly marked up with all manner of operators. The opcode is the action that DIG took, in this case a query. Status is an important one to note; in this case, there was no error reported. This field may show one of the following statuses when a query is invoked:
NOERROR - Everything's cool. The zone is being served from the requested authority without issues.
SERVFAIL - The name that was queried exists, but there's no data or invalid data for that name at the requested authority.
NXDOMAIN - The name in question does not exist, and therefore there is no authoritative DNS data to be served.
REFUSED - Not only does the zone not exist at the requested authority, but their infrastructure is not in the business of serving things that don't exist at all.
Next line starts out with flags - these are options that can be set to determine which sections of the answer get printed, or determine the timeout and retry strategies. The subsequent fields, Query, Answer, Authority and Additional provide the count of results for the DIG that was performed.
;; QUESTION SECTION: ;example.com. IN A
The question section reaffirms what you went looking for - in this case, DIG went looking for an IPv4 address (A Record) at example.com.
;; ANSWER SECTION: example.com. 3600 IN A 104.20.48.182 ;; Query time: 8 msec ;; SERVER: 198.51.44.1#53(198.51.44.1) ;; WHEN: Fri Jul 8 10:55:40 2016 ;; MSG SIZE rcvd: 45
We see that example.com, with a TTL of 3600 seconds (1 hour) has an A record - 104.20.48.182.
Query time shows how long it took to get the DNS response back from the server, which is listed on the next line. You can also see the exact moment in time that I requested this information, and how many bytes the response contained.
That, in a nutshell, is your basic run-of-the-mill DIG query and the components thereof. For more information on DIG, stay tuned to NS1's technical articles for an advanced DIG resource document!
This is the first part of our series on using DIG. You can read the second post on Using DIG +trace here.