Verifying DNS configurations

This article explains use of the open source "dig" tool to verify your Slicehost DNS configuration as a follow-up to our DNS Administration Guide.

Trust, but verify

It's a good idea to ensure that the changes you made are getting out to the rest of the world properly. Checking your DNS records right after a change gives you a chance to catch a mistake before the information is propagated to other name servers.

The examples below will assume you're using Slicehost's DNS management tool to manage your domain, and the verification steps will shadow the sequence presented in our DNS Administration Guide. This article should still be helpful if you're managing your DNS elsewhere, however.

Install dig

First, see if you have the "dig" command available on your Linux command line (it isn't installed by default on our Linux slice images). Try entering the following on the command line:


If you got a "command not found" response, you'll need to install your distribution's DNS utilities package. If you got a screen full of gobbledygook about "ROOT-SERVERS.NET", it's installed. Don't worry about what all that stuff means just yet, most of it will make sense before we're done.

On a slice running Fedora, CentOS, or Red Hat, you can install dig with the following command:

sudo yum install bind-utils

On a Debian or Ubuntu slice, you'll want to install dig via aptitude:

sudo aptitude install dnsutils

On a Gentoo slice, you install dig with:

emerge bind-tools

And if your slice is running Arch Linux, you install with:

pacman -S dnsutils

If you're testing from a Windows computer, you can install the open source dig tool into Cygwin and the same commands will work. That install process is beyond the scope of this article.

Mac OS X 10.5 and later versions include dig by default. It can be accessed in a terminal (command-line) session, e.g. with

It is also possible to run dig through some third-party websites, such as Geektools.

Testing A records

The first step in setting up DNS for a domain is to create a zone for the domain. Next we would create one or more A records to tie the domain and subdomains to IP addresses. The A records, then, will be the first part of the DNS zone we will verify.

Domain A record

Assuming that the domain is "" and the slice's public IP is "111.222.333.444", we would test the A record by running dig with the following arguments:

dig +short

The response would come back:


If you run that command for your own domain and don't get the IP address back that you expected, you'll want to check your configuration for any mistakes. The most common problem at this point would be a lack of a period at the end of the main A record ("" instead of "").

Subdomain A record

The next step we performed in our DNS administration guide was to set up A records for any subdomains. Subdomains are prefixed to the front of your main domain, like "" and "".

Assuming that we created a subdomain named "www" (note the lack of a trailing period) with the same slice's public IP address ("111.222.333.444"), we could run a similar command to ensure that it is configured properly:

dig +short

The response would come back:


If you don't get the correct IP address back from dig, go back to the configuration and check for mistakes. In this case remember that we don't want a period appended to the end of the subdomain name, since the lack of a trailing period tells the DNS server the label "www" will be prefixed to "".

Testing CNAME records

Slicehost's DNS Administration Guide next demonstrates how to configure a CNAME. Remember that a CNAME is an alias for an existing domain or subdomain. If we have followed the DNS Administration Guide and this article so far, we can assume that:

     1. We have created a domain called

     2. We added an A record for so that resolves to "111.222.333.444"

     3. We added an A record for a subdomain called for which we also used the IP address "111.222.333.444"

     4. That the A records have all been tested and are working

     5. We have added a CNAME record that maps the subdomain "mail" to

Our hope, then, is that when we check "" against the DNS server it will resolve to "111.222.333.444". To find out for sure we would run the following command:

dig +short

And if all went according to plan, we would get back:

That response would show that the DNS server resolved to, and then resolved to 111.222.333.444. Just what we wanted!

If we had set the CNAME Data field to "", the response from dig would have been:

The first part of the output should be the same as the "Data" field in the DNS tool's CNAME page. You could have more than one domain name listed in the first part of the output if the CNAME you used is itself a CNAME to another domain name.

The second part of dig's output should be the IP address you wanted "" to point to. That IP address should match the A record for the last domain name in the CNAME chain (in the example above, the address of "domain.

Testing NS records

The next item in our curriculum will be the NS records for the zone. To check the NS records we would enter:

dig +short NS

We're set if the response comes back as:

If we don't see the Slicehost nameserver addresses in dig's results we'll want to go back to the DNS tool and check the configuration there, again keeping an eye out for rogue or missing periods.

Testing MX records

Similar to CNAME records, MX records need to be directed to an existing A record (a domain or subdomain that ultimately resolves to an IP address). Once our MX record(s) are configured, we can test them with:

dig +short MX

The result we would expect, following the guide:


This response tells us that the only mail server configured in DNS is and that it has an MX priority of 10 (as set in the "Auxiliary Info" field in our DNS tool's MX Record form). As usual, if you don't see the expected result, check the configuration in the DNS tool.

To ensure the IP address is correct we could use dig to check the A record for the hostname this command returned to us, or we could drop the "+short" option from the dig test to see more information about the mail server. If you've been following along in this article, however, you will have already verified the mail server's A record in a previous step.

You can repeat this "dig MX" test as you add MX records for any secondary and tertiary mail servers. Dig's output will show you all the servers and their MX priorities. For example, for:

dig +short MX

The result might be:


Testing reverse DNS

If we set up reverse DNS (RDNS) settings for any of our hosts — a good idea for email servers — we can confirm those settings as well. Assuming we configured a reverse DNS name of "" for our "111.222.333.444" IP address, we would issue the command:

dig +short -x 111.222.333.444

The result should then be:

If we had not set a reverse DNS record we would see Slicehost's default RDNS record, something like:


That completes the basic suite of tests that we might (and should) perform when we use Slicehost's DNS tool to configure DNS records for our domains, subdomains and hosts. In the next article in this series we'll look at some further tests you can perform to make sure your changes get out to the rest of the Internet the way they should.

Article Comments:

Avin commented Fri Nov 18 06:15:27 UTC 2011:

I have configured DNS record using slicehost DNS management tool. Which is really easy to manage records in Slicehost DNS manager.

But I am facing following issue: 1) My some website(sub-domain) which I not access regularly fail to resolve when I try to access in a some days.

2) Is this because I haven't access it daily .

3) Any setting remaining in Slicehost DNS session to keep site alive forever

4) Any tool can I use to keep my site alive.

My Web Server Details: Apache2 Passenger Module

sysadmin commented Tue Oct 02 14:52:30 UTC 2012:

Avin, the answer to the point 2) is definetely "no". DNS records do live "forever" once they have been set up (if DNS-servers are working correctly and domain name is renewed regularly). First of all you should check that ALL the name servers return the same results. I have often seen similar issues when one DNS-server works well, and others - don't. In this case random resolving timeouts occur due to the nature of round robin algorithm.

Want to comment?

(not made public)


(use plain text or Markdown syntax)