DNS's feilds described
Surendra.anne
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-gif on page-gif, 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.