Managing Name Servers

A simplified vision of the DNS tree would persuade the reader that each domain is associated with a server. That is not true for several reasons:

As it can be seen, after updates there are database inconsistencies among the server running primary and the servers running secondary for the zone. There are also inconsistencies with the cached data. These inconsistencies are more or less tolerated by the different application level servers and by users querying the DNS.

Each zone (set of domains managed under the same authority) is managed by an individual, the zone administrator [#!rfc-1033!#]. The administrator is responsible for the correct set up of the zone. Setting up a zone database involves the definition of the zone itself and the introduction of the different RRs belonging to it. When a server delegates its authority about a sub-zone to a server belonging to one of its sub-zones, glue resource records must be inserted. These special RRs associate attributes with names outside the zone, introducing non authoritative data needed to allow a server querying about the sub-zone, to be informed about the set of servers knowing it (and their addresses), otherwise it would be impossible to get the sub-zone servers addresses. Moreover, each zone must be set up with a set of parameters about the periodicity of zone transfers from primary to secondary servers, retry timers if the previous zone transfer has failed, and period of validity of a zone if its primary server cannot be contacted during a long period of time. Each zone has also a version number. This number is used to avoid unnecessary zone transfers. Version numbers must always increase otherwise secondary server updates will stop.

It is rather easy to introduce errors in the DNS database. Here is a list of some of the more frequent ones:

The introduction of all or some of these errors is not easily avoidable because there are hundreds or even thousands of different administrators involved. These administrators tend to be less and less skilled as long as we walk far from the root domain or at least far from the ``top level domains'' (domains like ``.edu'', ``.com'', ``.mil'', and country domains), or when their countries have recently connected to the Internet, like our own. However, these errors are not easily detectable because the distributed and decentralized nature of the DNS system, as well as its ability to survive to wrong and inconsistent data, allows the system to continue to produce useful work even in the presence of errors. Moreover, there is no possibility to run a test over some sort of ``global state'' of the database.

Generally, when the administrator of a zone delegates authority over a delegated zone (a descendent new branch of the tree), he or she tries, as much as ``his or her time'' allows it, to analyze the set up of the delegated name server. However, it is very difficult to do it in a systematic way and, as soon as the delegated server appears to be well managed, it is up to its administrator to take care of its future. Errors will only show up in extreme strange behaved situations, when users complain or by manual inspection. We have been deeply involved with the set up of the top level domain for Portugal (``pt.'') and we are responsible for delegating new zones under this domain, that's why the idea of building a tool to help DNS administration was born.