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.
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:
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 Terminal.app.
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 "domain.com" 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 @dns1.stabletransit.com +short domain.com
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 ("domain.com" instead of "domain.com.").
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 "www.domain.com" and "mail.domain.com".
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 @dns1.stabletransit.com +short www.domain.com
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 "domain.com".
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 domain.com
2. We added an A record for domain.com so that domain.com resolves to "111.222.333.444"
3. We added an A record for a subdomain called www.domain.com 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 www.domain.com.
Our hope, then, is that when we check "mail.domain.com" against the DNS server it will resolve to "111.222.333.444". To find out for sure we would run the following command:
dig @dns1.stabletransit.com +short mail.domain.com
And if all went according to plan, we would get back:
That response would show that the DNS server resolved mail.domain.com to www.domain.com, and then resolved www.domain.com to 111.222.333.444. Just what we wanted!
If we had set the CNAME Data field to "domain.com.", 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 "mail.domain.com" 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 @dns1.stabletransit.com +short NS domain.com
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 @dns1.stabletransit.com +short MX domain.com
The result we would expect, following the guide:
This response tells us that the only mail server configured in DNS is mail.domain.com 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 @dns1.stabletransit.com MX domain.com" 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 @dns1.stabletransit.com +short MX domain.com
The result might be:
30 mail1.domain.com. 20 mail1.domain.com. 10 mail.domain.com.
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 "mail.domain.com" for our "111.222.333.444" IP address, we would issue the command:
dig @dns1.stabletransit.com +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.