Skip to main content Skip to search
Alex Vayl
Posted by
Alex Vayl on
July 19, 2016

Using dig +trace to Understand DNS Resolution from Start to Finish

Sign Up for Our Newsletter

This is the second part of our series on using DIG. You can read the first post on Decoding DIG Output here.

The dig command is a powerful tool for troubleshooting queries and responses received from the Domain Name Service (DNS). It is installed by default on many operating systems, including Linux and Mac OS X. It can be installed on Microsoft Windows as part of Cygwin.

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

One of the myriad things dig can do is to perform a recursive DNS resolution and display all of the steps that it took in your terminal. This is extremely useful for understanding not only how the DNS works, but for determining if there is an issue somewhere within the DNS name hierarchy that is causing resolution failures within your own zone, or domain.

Does your enterprise face some of these common DNS challenges?

Learn more about the most common enterprise DNS challenges in automation, change propagation, and traffic management and how to resolve them in our guide, Three Common Enterprise DNS Challenges and How to Solve Them.

First, let’s briefly review how a query recursively receives a response in a typical DNS resolution scenario:

  1. You as the DNS client (or stub resolver) query your recursive resolver for
  2. Your recursive resolver queries the root name server for
  3. The root name server refers your recursive resolver to the .com Top-Level Domain (TLD) authoritative server.
  4. Your recursive resolver queries the .com TLD authoritative server for
  5. The .com TLD authoritative server refers your recursive server to the authoritative servers for
  6. Your recursive resolver queries the authoritative servers for, and receives as the answer.
  7. Your recursive resolver caches the answer for the duration of the time-to-live (TTL) specified on the record, and returns it to you.

The above process basically looks like this:

You can watch this process in action by running dig with the +trace parameter, as in:

Step 1

$ dig +trace

Step 2

; <<>> DiG 9.10.2 <<>> +trace
;; global options: +cmd
. 13382 IN NS
. 13382 IN NS
. 13382 IN NS
. 13382 IN NS
;; Received 397 bytes from in 36 ms

Step 3

com. 172800 IN NS
com. 172800 IN NS
com. 172800 IN NS
com. 172800 IN NS
;; Received 737 bytes from in 55 ms

Step 4 172800 IN NS 172800 IN NS 172800 IN NS 172800 IN NS
;; Received 781 bytes from in 169 ms

Step 5 300 IN A
;; Received 187 bytes from in 26 ms

This is the exact process that goes on behind-the-scenes every time you type a URL into your web browser, or fire up your email client. This also illustrates why both DNS answer accuracy and answer speed is so important: if the answer is inaccurate, you may need to repeat this process several times; and if the speed with which you receive an answer is slow, then it will make everything you do online seem to take longer than it should. Ensuring both answer accuracy and speed is at the core of NS1’s value proposition.

Request a Demo

Contact Us

Looking for help? Please email [email protected]

Get Pricing

Learn More About our Partner Program