Checking your domaine: why and how

Stephane Bortzmeyer

$Date: 2004-01-27 12:33:38 $

Table of Contents

Why?
How?

Why?

My domain works. Why should I test it? Because the appearence of working is not enough. Your domain may work only from some places in the Internet (for instance because not all your nameservers are synchronized). Or your domain may be terribly slow because of a configuration error^[1]. Or your domain may work only with some DNS resolvers but not all. This is why you should really implement some form of quality assessment, in other words, testing.

All the studies show that most domains, even the TLD, have configuration problems. For instance, Generic NIC monitoring tool monitors the ccTLD and find many of them in various states of breakage. A paper by Jim Reid also emphasizes the bad consequences of the lack of quality control in most ccTLD. A study by Mark Foster says the same thing.

When your TLD is fine, you can start chasing defects in your subzones. For instance, you may decide, like it is done in Germany, Brazil or France, or by RIPE-NCC for in-addr.arpa domains, to require a proper setup of subzones before or during delegation. Just be sure that this requirment is written in the contract you have with your registrants so that people are warned in advance. You can either test once before the delegation (and suspend the delegation as long as the domain does not really work) or do the test periodically and, if there is a failure, freeze or delete the domaine after, say, three consecutive failures.

How?

You can test your domain with any DNS debugging tool such as dig. However, when you have to conduct several tests on all your name servers, manually running dig has its limitations. You can either wrap it into a script or use an already made tool. We will study check_soa and ZoneCheck.

check_soa

check_soa was written by Liu and Albitz and is described in their DNS book. You can retrieve the source code for all their examples, including check_soa.

check_soa asks all the name servers of the given domain and simply checks that they reply and are authoritative for the domain. It is a very simple tool, but which catches most of the configuration failures.

You run it from the Unix command line:

% check_soa ml
There was no response from dogon.sotelma.ml
There was no response from ns.ucad.sn
There is no name server running on ciwara1.sotelma.ml
ciwara.sotelma.ml has serial number 2002052400
There is no name server running on neene.afriq.net

We can see here that only one out of five name servers for this ccTLD are actually responding properly. Three seem dead (use ping to check) and one has no name server running (BIND stopped and was never restarted?).

On another domain:

% check_soa bd
DNS.bd is not authoritative for bd
There was no response from DNS1.bd

One of the servers is in "lame delegation" which means that it is listed as authoritative but is not. In that case, it is the primary and there was a syntax error in the configuration file of BIND, preventing it from starting properly. Very often, a lame delegation is due to a server which was listed for secondary service, without bothering to ask its administrators to set it up.

You can see that check_soa catches a lot of problems. If you want more thorough tests, we will use a more powerful tool.

ZoneCheck

ZoneCheck is written and maintained by Stephane d'Alu at AFNIC.

You can use ZoneCheck from the Web or you can download it and install it locally, for instance as a tool to check your subzones. In the examples here, we will use it locally.

Let's test other ccTLD with more subtle errors:

% zonecheck dj
[Warnings not displayed]
       _____________
     ,-------------.|
~~~~ |    Fatal    || ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     `-------------'

[TEST SOA record present]: Answer refused from serveur
=> ns.ripe.net./193.0.0.193

==> FAILED (and 4 warning(s))

We added various verboseness options to see what's going on. Here, ns.ripe.net is listed as a nameserver for '.dj' but it refused to answer (probably another form of lame delegation). Fatal errors from ZoneCheck should be taken seriously.

This domain has another fatal error:

% zonecheck us
     _____________
     ,-------------.|
~~~~ |    Fatal    || ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     `-------------'

Server doesn't listen/answer on port 53 for TCP protocol
 | Ref: IETF RFC1035 (p.32 4.2. Transport)
 |  The DNS assumes that messages will be transmitted as datagrams or in a
 |  byte stream carried by a virtual circuit.  While virtual circuits can be
 |  used for any DNS activity, datagrams are preferred for queries due to
 |  their lower overhead and better performance.
 `----- -- -- - -  -
=> c.gtld.biz./209.173.60.65

==> FAILED (and 7 warning(s))

Do note that ZoneCheck displays the specific section of the RFC which mandates the correct behavior (here, a DNS server must be reachable with TCP, not only UDP).

Another domain has no fatal errors but exhibit some warnings:

% zonecheck be
      _______________
     ,---------------.|
~~~~ |    Warning    || ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     `---------------'
[...]
Can't find reverse for the nameserver IP address
=> schaarbeek.ns.dns.be./213.181.36.60

==> SUCCEED (but 22 warning(s))

Here, a nameserver has no PTR record.

ZoneCheck is quite configurable: by default it uses the configuration file choosen by its author but you can change it to suit your local policy.

^[1]Resolvers, the DNS clients, may have to try several nameservers to find a good one, thus slowing the application.