Next: Writing the Master Files
Up: Running named
Previous: The named.boot File
Master files included by named, like named.hosts, always
have a domain associated with them, which is called the origin.
This is the domain name specified with the cache and
primary commands. Within a master file, you are allowed to
specify domain and host names relative to this domain. A name given in
a configuration file is considered absolute if it ends in a single
dot, otherwise it is considered relative to the origin. The origin all
by itself may be referred to using ``@''.
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
Fields are separated by spaces or tabs. An entry may be continued
across several lines if an opening brace occurs before the first newline,
and the last field is followed by a closing brace. Anything
between a semicolon and a newline is ignored.
- 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.
Andrew Anderson
Thu Mar 7 23:22:06 EST 1996