Determining why a domain won't resolve

[Andrew@Spry]

Because DNS depends on records in multiple places matching up, its common for things to be off, which in the worst cases will lead to the domain not being able to resolve.

The two tools I use when troubleshooting why a domain are not resolving are dig and whois. 'whois' is a command you can use to find the information the domain's registrar has for the domain. This will, among other things tell you the nameservers that the registrar is sending people to when they get requests about the domain. This can help make sure the registrar's records are what they should be.

Once you're certain the registrar's records are correct, dig is the tool to make sure that the records on the nameserver are correct. The 'dig' command has a number of options and different ways it can be invoked, but for basic DNS troubleshooting the two you'll find most useful are '+trace' and '@namserver'. The '+trace' option shows you each step the DNS search takes. This makes it much easier to determine which step in the lookup is failing. So to see each nameserver that is searched when looking up example.com, I would use the command 'dig example.com +trace'. The '@nameserver' will specify the nameserver that you want dig to contact when asking about the DNS records. You can use either a domain name or an IP address, however I usually use an IP address to specify a nameserver (unless querying localhost) as the whole point of testing DNS is that something isn't working as it should. So to see what address will be returned for example.com by the nameserver on the same computer I'm running dig from, I'd use "dig example.com @localhost". If I wanted to see what was returned by the nameserver at 64.79.200.111 I'd use "dig exampl.com @64.79.200.111".

Dig has a number of other options that you can use to determine other information regarding a domain's DNS records. To get all the details take a look at the man page for dig(1), or if you're not familiar with using the man pages, doing a Google search for "dig man" will bring up a number of online versions of dig's man page.

[Andrew@Spry]

So how do you isolate the problem when you've determined that the problem with the DNS records is on your nameserver? The first thing to do is to make sure that the nameserver is running and determine where the configuration and zone files are stored. The easiest way to do this is to run the command

ps faux|grep named

You should see something like

named     5635  0.0  0.0  69616  4400 ?        Ssl  Jul13   0:29 /usr/sbin/named -u named -t /var/named/chroot
root      5406  0.0  0.0   1604   512 ttyp0    S+   10:43   0:00      \_ grep named

or

named     5635  0.0  0.0  69616  4400 ?        Ssl  Jul13   0:29 /usr/sbin/named -u named 
root      5406  0.0  0.0   1604   512 ttyp0    S+   10:43   0:00      \_ grep named

If you don't see any output and just get the command line back (or only see the grep process), then named isn't running, and should be restarted.

If you do see the named process listed, you want to check if there is a '-t' option in the output, like the "-t /var/named/chroot" in the first example above. If it is there this tells you that the nameserver has been chroot'd, which will change the location of the files you need to look at. From this point on I'll assume that named hasn't been chroot'd, and refer to the default locations. If named has been placed in a chroot jail, prepend the directory listed after the '-t' option to any paths listed below.

Once you're certain that named is actually running, you want to check the config file, which is typically /etc/named.conf . The two things you want to make sure of in regards to the named.conf file is that the file's syntax is ok, and that it has a zone entry for the domain you are trying to troubleshoot. You can check the file's syntax using the named-checkconf command. The basic syntax for the command is

named-checkconf </path/to/named.conf>

If the syntax is ok there won't be any output, and you'll just get a prompt back. If there are problems you'll get a message complaining about those errors.

You should then look through the file to make sure that there is a zone section for the domain in question. A basic zone definition should look something like

zone "example.com" {
       type master;
       file "/var/named/example.com.db";
};

This example tells the nameserver that it is the master nameserver for the domain example.com, and that the file containing the DNS records for the domain is located at /var/named/example.com.db.

If you've gotten this far and still need to determine why a domain's records aren't resolving correctly, it's time to look at the file holding the domain's DNS records, typically called a zone file.

To start you should use the named-checkzone command. Like the named-checkconf command checks named's config file, this checks a zone file to make sure that it syntax is correct. The basic way to run the command is

named-checkzone <zone> <zone_file>

This will make sure that the syntax for the file is correct.

If you've run all of the checks above and still can't determine the problem, you may need to check if the nameserver is using views, which can cause problems if not setup correctly. If you're sure that views aren't the problem, and still can't determine why a domain isn't resolving, you're facing an unusual problem, and will need to look at the server's log files to determine why things aren't working correctly.