The DNS Database Files

All data contained in a master file is split up in resource records, or RRs for short. They make up the smallest unit of information available through DNS. Each resource record has a type. A records, for instance, map a hostname to an IP-address, and a CNAME record associates an alias for a host with its official hostname. As an example, take a look at figure- on page-, which shows the named.hosts master file for the virtual brewery.

Resource record representations in master files share a common format, which is

[domain] [ttl] [class] type rdata

domain

This is the domain name to which the entry applies. If no domain name is given, the RR is assumed to apply to the domain of the previous RR.

ttl

In order to force resolvers to discard information after a certain time, each RR is associated a ``time to live'', or ttl for short. The ttl field specifies the time in seconds the information is valid after it has been retrieved from the server. It is a decimal number with at most eight digits. If no ttl value is given, it defaults to the value of the minimum field of the preceding SOA record.

class

This is an address class, like IN for IP addresses, or HS for objects in the Hesiod class. For TCP/IP networking, you have to make this IN. If no class field is given, the class of the preceding RR is assumed.

type

This describes the type of the RR. The most common types are A, SOA, PTR, and NS. The following sections describe the var- ious types of RR's.

rdata

This holds the data associated with the RR. The format of this field depends on the type of the RR. Below, it will be described for each RR separately.

The following is an incomplete list of RRs to be used in DNS master files. There are a couple more of them, which we will not explain. They are experimental, and of little use generally.

SOA

This describes a zone of authority (SOA means ``Start of Authority''). It signals that the records following the SOA RR contain authoritative information for the domain. Every master file included by a primary statement must contain an SOA record for this zone. The resource data contains the following fields:

origin

This is the canonical hostname of the primary name server for this domain. It is usually given as an absolute name.

contact

This is the email address of the person responsible for maintaining the domain, with the `@' character replaced by a dot. For instance, if the responsible person at the Virtual Brewery is janet, then this field would contain janet.vbrew.com.

serial

This is the version number of the zone file, expressed as a single decimal number. Whenever data is changed in the zone file, this number should be incremented. The serial number is used by secondary name servers to recognize when zone information has changed. To stay up to date, secondary servers request the primary server's SOA record at certain intervals, and compare the serial number to that of the cached SOA record. If the number has changed, the secondary servers transfers the whole zone database from the primary server.

refresh

This specifies the interval in seconds that the sec- ondary servers should wait between checking the SOA record of the primary server. Again, this is a deci- mal number with at most eight digits. Generally, the network topology doesn't change too often, so that this number should specify an interval of roughly a day for larger networks, and even more for smaller ones.

retry

This number determines the intervals at which a sec- ondary server should retry contacting the primary server if a request or a zone refresh fails. It must not be too low, or else a temporary failure of the server or a network problem may cause the secondary server to waste network resources. One hour, or perhaps one half hour, might be a good choice.

expire

This specifies the time in seconds after which the server should finally discard all zone data if it hasn't been able to contact the primary server. It should normally be very large. Craig Hunt ([ GETST "hunt-tcpip" ]) recommends 42 days.

minimum

This is the default ttl value for resource records that do not explicitly specify one. This requires other name servers to discard the RR after a certain amount of time. It has however nothing to do with the time after which a secondary server tries to update the zone information. minimum should be a large value, especially for LANs where the network topology almost never changes. A value of around a week or a month is probably a good choice. In the case that single RRs may change more frequently, you can still assign them different ttl's.

A

This associates an IP address with a hostname. The resource data field contains the address in dotted quad nota- tion. For each host, there must be only one A record. The hostname used in this A record is considered the official or canonical hostname. All other hostnames are aliases and must be mapped onto the canonical hostname using a CNAME record.

NS

This points to a master name server of a subordinate zone. For an explanation why one has to have NS records, see section 3.6. The resource data field contains the hostname of the name server. To resolve the hostname, an additional A record is needed, the so-called glue record which gives the name server's IP address.

CNAME

This associates an alias for a host with its canonical hostname. The canonical hostname is the one the master file provides an A record for; aliases are simply linked to that name by a CNAME record, but don't have any other records of their own.

PTR

This type of record is used to associate names in the in- addr.arpa domain with hostnames. This is used for reverse map- ping of IP addresses to hostnames. The hostname given must be the canonical hostname.

MX

This RR announces a mail exchanger for a domain. The rea- sons to have mail exchangers are discussed in section 14.4.1 in chapter 14.. The syntax of an MX record is

[domain] [ttl] [class] MX preference host

host names the mail exchanger for domain. Every mail exchanger has an integer preference associated with it. A mail transport agent who desires to deliver mail to domain will try all hosts who have an MX record for this domain until it succeeds. The one with the lowest preference value is tried first, then the others in order of increasing preference value.

HINFO

This record provides information on the system's hardware and software. Its syntax is

[domain] [ttl] [class] HINFO hardware software

The hardware field identifies the hardware used by this host. There are special conventions to specify this. A list of valid names is given in the ``Assigned Numbers'' (RFC 1340). If the field contains any blanks, it must be enclosed in double quotes. The software field names the operating sys- tem software used by the system. Again, a valid name from the ``Assigned Numbers'' RFC should be chosen.