Tải bản đầy đủ
[Appendix C] C.3 Zone File Records

[Appendix C] C.3 Zone File Records

Tải bản đầy đủ

[Appendix C] C.3 Zone File Records

C.3.1 Standard Resource Records
The format of standard resource records, sometimes called RRs, is defined in RFC 1033, the Domain
Administrators Operations Guide. The format is:
[name] [ttl] class type data
The individual fields in the standard resource record are:
name
This is the name of the object affected by this resource record. The named object can be as
specific as an individual host, or as general as an entire domain. The string entered for name is
relative to the current domain unless a fully qualified domain name is used. [4] Certain name
values have special meaning. These are:

A blank name field denotes the current named object. The current name stays in force
until a new name value is encountered in the name field. This permits multiple RRs to
be applied to a single object without having to repeat the object's name for each record.
..
Two dots in the name field refer to the root domain. However, a single dot (the actual
name of the root) also refers to the root domain, and is more commonly used.
@
A single at-sign (@) in the name field refers to the current origin. The origin is a domain
name derived by the system from the current domain name or explicitly set by the
system administrator using the $ORIGIN command.
*
An asterisk in the name field is a wildcard character. It stands for a name composed of
any string. It can be combined with a domain name or used alone. Used alone, an
asterisk in the named field means that the resource record applies to objects with names
composed of any string of characters plus the name of the current domain. Used with a
domain name, the asterisk is relative to that domain. For example, *.bitnet. in the name
field means any string plus the string .bitnet.
[4] The FQDN must be specified all the way to the root; i.e., it must end with a
dot.
ttl

file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (2 of 16) [2001-10-15 09:19:23]

[Appendix C] C.3 Zone File Records

Time-to-live defines the length of time in seconds that the information in this resource record
should be kept in the cache. ttl is specified as a numeric value up to eight characters in
length. If no value is set for ttl, it defaults to the value defined for the entire zone file in the
minimum field of the SOA record.
class
This field defines the address class of the resource record. The Internet address class is IN. All
resource records used by Internet DNS have IN in this field, but it is possible for a zone file to
hold non-Internet information. For example, information used by the Hesiod server, a name
server developed at MIT, is identified by HS in the class field, and chaosnet information is
identified by a CH in the class field. All resource records used in this book have an address
class of IN.
type
This field indicates the type of data this record provides. For example, the A type RR provides
the address of the host identified in the name field. All of the standard resource record types
are discussed in this appendix.
data
This field contains the information specific to the resource record. The format and content of
the data field vary according to the resource record type. The data field is the meat of the RR.
For example, in an A record, the data field contains the IP address.
In addition to the special characters that have meaning in the name field, zone file records use these
other special characters:
;
The semicolon is the comment character. Use the semicolon to indicate that the remaining data
on the line is a comment.
( )
Parentheses are the continuation characters. Use parentheses to continue data beyond a single
line. After an opening parenthesis, all data on subsequent lines is considered part of the current
line until a closing parenthesis.
\x
The backslash is an escape character. A non-numeric character following a backslash (\) is
taken literally and any special meaning that the character may ordinarily have is ignored. For
example, \; means a semicolon - not a comment.
\ddd
The backslash can also be followed by three decimal numbers. When the escape character is
used in this manner the decimal numbers are interpreted as an absolute byte value. For
example, \255 means the byte value 11111111.
file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (3 of 16) [2001-10-15 09:19:23]

[Appendix C] C.3 Zone File Records

The same general resource record format is used for each of the resource records in a zone file. Each
resource record is described below.
C.3.1.1 Start of Authority record
The Start of Authority (SOA) record marks the beginning of a zone, and is usually the first record in a
zone file. All of the records that follow are part of the zone declared by the SOA. Each zone has only
one SOA record; the next SOA record encountered marks the beginning of another zone. Because a
zone file is normally associated with a single zone, it normally contains only one SOA record.
The format of the SOA record is:
[zone] [ttl] IN SOA origin contact (
serial
refresh
retry
expire
minimum
)
The components of the SOA record are:
zone
This is the name of the zone. Usually the SOA name field contains an at-sign (@). When used
in an SOA record, the at-sign refers back to the domain name declared in the named.boot
primary statement that points to this zone file.
ttl
Time-to-live is left blank on the SOA record.
IN
The address class is IN for all Internet RRs.
SOA
SOA is the resource record type. All the information that follows this is part of the data field
and is specific to the SOA record.
Iorigin
This is the hostname of the primary master server for this domain. It is normally written as a
fully qualified domain name. For example, almond is the master server for nuts.com, so this
field contains almond.nuts.com. in the SOA record for nuts.com.
contact

file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (4 of 16) [2001-10-15 09:19:23]

[Appendix C] C.3 Zone File Records

The email address of the person responsible for this domain is entered in this field. The address
is modified slightly. The at-sign (@) that usually appears in an Internet email address is
replaced by a dot. Therefore, if david@almond.nuts.com is the mailing address of the
administrator of the nuts.com domain, the nuts.com SOA record contains
david.almond.nuts.com. in the contact field.
serial
This is the version number of the zone file. It is an eight-digit numeric field usually entered as
a simple number, e.g., 117. However, the composition of the number is up to the administrator.
Some choose a format that shows the date the zone was updated, e.g., 92031100. Regardless of
the format, the important thing is that the serial number must increase every time the data in
the zone file is modified.
The serial field is extremely important. It is used by the secondary master servers to determine
if the zone file has been updated. To make this determination, a secondary server requests the
SOA record from the primary server and compares the serial number of the data it has stored to
the serial number received from the primary server. If the serial number has increased, the
secondary server requests a full zone transfer. Otherwise it assumes that it has the most current
zone data. You must increment the serial number each time you update the zone data. If you
don't, the new data will not be disseminated to the secondary servers.
refresh
This specifies the length of time that the secondary server should wait before checking with the
primary server to see if the zone has been updated. Every refresh seconds, the secondary
server checks the SOA serial number to see if the zone file needs to be reloaded. Secondary
servers check the serial numbers of their zones whenever they restart or receive a SIGHUP
signal. But it is important to keep the secondary server's database current with the primary
server, so named does not rely on these unpredictable events. The refresh interval provides
a predictable cycle for reloading the zone that is controlled by the domain administrator.
The value used in refresh is a number, up to eight digits long, that is the maximum number
of seconds that the primary and secondary servers' databases can be out of sync. A low
refresh value keeps the data on the servers closely synchronized, but a very low refresh
value is not usually required. A value set lower than needed places an unnecessary burden on
the network and the secondary servers. The value used in refresh should reflect the reality
of how often your domain database is updated.
Most sites' domain databases are very stable. Systems are added periodically, but not generally on an
hourly basis. When you are adding a new system, you can assign the hostname and address of that
system before the system is operational. You can then install this information in the name server
database before it is actually needed, ensuring that it is disseminated to the secondary servers long
before it has to be used.
If extensive changes are planned, the refresh time can be temporarily reduced while the changes
are underway. Therefore, you can normally set refresh time high, reducing load on the network
file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (5 of 16) [2001-10-15 09:19:24]

[Appendix C] C.3 Zone File Records

and servers. Two (43200 seconds) to four (21600 seconds) times a day for refresh is adequate for
many sites.
The process of retrieving the SOA record, evaluating the serial number and, if necessary,
downloading the zone file is called a zone refresh. Thus the name refresh is used for this value.
retry
This defines how long secondary servers should wait before trying again if the primary server
fails to respond to a request for a zone refresh. retry is specified in seconds and can be up to
eight digits long.
You should not set the retry value too low. If a primary server fails to respond, the server or
the network could be down. Quickly retrying a down system gains nothing and costs network
resources. A secondary server that backs up a large number of zones can have problems when
retry values are short. If the secondary server cannot reach the primary servers for several of its
zones, it can become stuck in a retry loop. [5] Avoid problems; use an hour (3600) or a half
hour (1800) for the retry value.
[5] The server may alternate between periods when it fails to respond and when it
resolves queries, or it may display the error "too many open files."
expire
This defines how long the zone's data should be retained by the secondary servers without
receiving a zone refresh. The value is specified in seconds and is up to eight digits long. If after
expire seconds the secondary server has been unable to refresh this zone, it should discard
all of the data.
expire is normally a very large value. 3600000 seconds (about 42 days) is commonly used.
This says that if there has been no answer from the primary server to refresh requests repeated
every retry seconds for the last 42 days, discard the data. 42 days is a good value.
minimum
This is the value used as the default ttl in all resource records where an explicit ttl value is not
provided. This is a number, up to eight digits long, that specifies how many seconds resource
records from this zone should be held in a remote host's cache.
Make this a large value. Most of the records in a zone remain unchanged for long periods of
time. Hosts are added to a zone, but hostnames (if they are well chosen) and addresses are not
frequently changed. Forcing remote servers to query again for data that has not changed, just
because it had a short ttl, is a waste of resources. If you plan to change a record, put a short ttl
on that record; don't set the entire zone to a short ttl by setting a low minimum. Use a short
minimum only if the entire database is being replaced. Use at least a week (604800) for normal
operation.
file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (6 of 16) [2001-10-15 09:19:24]

[Appendix C] C.3 Zone File Records

A sample SOA record for the nuts.com domain is:
@

IN

SOA

almond.nuts.com. david.almond.nuts.com. (
92031101
; serial
43200
; refresh twice a day
3600
; retry every hour
3600000
; expire after 1000 hours
2419200
; default ttl is one month
)

Notice the serial number in this SOA. The serial number is in the format yymmddvv - where yy is the
year, mm is the month, dd is the day, and vv is the version written that day. This type of serial number
allows the administrator to track what day the zone was updated. Adding the version number allows
for multiple updates in a single day. This zone file was created March 11, 1992, and it is the first
update that day.
This SOA record also says that almond is the primary server for this zone and that the person
responsible for this zone can be reached at the email address david@almond.nuts.com. The SOA tells
the secondary servers to check the zone for changes twice a day and to retry every hour if they don't
get an answer. If they retry a thousand times and never get an answer, they should discard the data for
this zone. Finally, if an RR in this zone does not have an explicit ttl, it will default to 1 month.
C.3.1.2 Name server record
Name server (NS) resource records identify the authoritative servers for a zone. These records are the
pointers that link the domain hierarchy together. NS records in the top-level domains point to the
servers for the second-level domains, which in turn contain NS records that point to the servers for
their subdomains. Name server records pointing to the servers for subordinate domains are required
for these domains to be accessible. Without NS records, the servers for a domain would be unknown.
The format of the NS RR is:
[domain] [ttl] IN NS server
domain
The name of the domain for which the host specified in the server field is an authoritative
name server.
ttl
Time-to-live is usually blank.
IN
The address class is IN.
file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (7 of 16) [2001-10-15 09:19:24]

[Appendix C] C.3 Zone File Records

NS
The name server resource record type is NS.
server
The hostname of a computer that provides authoritative name service for this domain.
Usually domains have at least one server that is located outside of the local domain. The server
name cannot be specified relative to the local domain; it must be specified as a fully qualified
domain name. To be consistent, many administrators use fully qualified names for all servers,
even though it is not necessary for servers within the local domain.
C.3.1.3 Address record
The majority of the resource records in a named.hosts zone file [6] are address records. Address
records are used to convert hostnames to IP addresses, which is the most common use of the DNS
database.
[6] Chapter 8 describes the various named configuration files.
The address RR contains the following:
[host] [ttl] IN A address
host
The name of the host whose address is provided in the data field of this record. Most often the
hostname is written relative to the current domain.
ttl
Time-to-live is usually blank.
IN
The address class is IN.
A
The address resource record type is A.
address
The IP address of the host is written here in dotted decimal form, e.g., 128.66.12.2.
A glue record is a special type of address record. Most address records refer to hosts within the zone,
but sometimes an address record needs to refer to a host in another zone. This is done to provide the
address of a name server for a subordinate domain. Recall that the NS record for a subdomain server
file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (8 of 16) [2001-10-15 09:19:24]

[Appendix C] C.3 Zone File Records

identifies the server by name. An address is needed to communicate with that server, so an A record
must also be provided. The address record, combined with the name server record, links the domains
together - thus the term "glue record."
C.3.1.4 Mail exchanger record
The mail exchanger (MX) record redirects mail to a mail server. It can redirect mail for an individual
computer or an entire domain. MX records are extremely useful for domains that contain some
systems that don't run mail software. Mail addressed to those systems can be redirected to computers
that do run mail software. MX records are also used to simplify mail addressing by redirecting mail to
servers that understand the simplified addresses.
The format of the MX RR is:
[name] [ttl] IN MX preference host
name
The name of a host or domain to which the mail is addressed. Think of this as the value that
occurs after the @ in a mailing address. Mail addressed to this name is sent to the mail server
specified by the MX record's host field.
ttl
Time-to-live is usually blank.
IN
The address class is IN.
MX
The Mail Exchanger resource record type is MX.
preference
A host or domain may have more than one MX record associated with it. The preference field
specifies the order in which the mail servers are tried. Servers with low preference numbers are
tried first, so the most preferred server has a preference of 0. Preference values are usually
assigned in increments of 5 or 10, so that new servers can be inserted between existing servers
without editing the old MX records.
host
The name of the mail server to which mail is delivered when it is addressed to the host or
domain identified in the name field.
Here is how MX records work. If a remote system understands how to use MX records and has mail
to send to a host, it requests the host's MX records. DNS returns all of the MX records for the
specified host. The remote server chooses the MX with the lowest preference value and attempts to
file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (9 of 16) [2001-10-15 09:19:24]

[Appendix C] C.3 Zone File Records

deliver the mail to that server. If it cannot connect to that server, it will try each of the remaining
servers in preference order until it can deliver the mail. If no MX records are returned by DNS, the
remote server delivers the mail directly to the host to which the mail is addressed. MX records only
define how to redirect mail. The remote system and the mail server perform all of the processing that
actually delivers the mail.
Because the remote system will first try to use an MX record, many domain administrators include
MX records for every host in the zone. Many of these MX records point right back to the host to
which the mail is addressed, e.g., an MX for almond with a host field of almond.nuts.com. These
records are used to reduce the processing load of the remote computer. A nice gesture!
An important use for MX records is to allow mail to non-Internet sites to be delivered using Internetstyle addressing. MX records do this by redirecting the mail to computers that know how to deliver
the mail to non-Internet networks. For example, sites using uucp can register an Internet domain
name with UUNET. UUNET uses MX records to redirect Internet mail addressed to these nonconnected sites to uunet.uu.net, which delivers the mail to its final destination via uucp.
Here are some MX examples. All of these examples are for the imaginary domain nuts.com. In the
first example, mail addressed to hazel.nuts.com is redirected to almond.nuts.com with this MX record:
hazel

IN

MX

10 almond

The second example is an MX record used to simplify mail addressing. People can send mail to any
user in this domain without knowing the specific computer that the user reads his mail on. Mail
addressed to user@nuts.com is redirected by this MX record to almond, which is a mail server that
knows how to deliver mail to every individual user in the domain.
nuts.com.

IN

MX

10 almond.nuts.com.

The last example is an MX record that redirects mail addressed to any host within the domain to a
central mail server. Mail addressed to any host, pecan.nuts.com, acorn.nuts.com, or
anything.nuts.com, is redirected to almond. This is the most common use of the wildcard character
(*).
*.nuts.com.

IN

MX

10 almond.nuts.com.

In these examples, the preference is 10 so that a mail server with a lower preference number can
be added to the zone without changing the existing MX record. Also notice that the host names in the
first example are specified relative to the nuts.com domain, but the other names are not relative
because they end in a dot. All of these names could have been entered as relative names, because they
all are hosts in the nuts.com domain. Fully qualified names were used only to vary the examples.
Finally, the wildcard MX record applies only to hosts that do not have a specific MX record. If the
specific record for hazel is in the same configuration as the wildcard record, the wildcard MX does
not apply to hazel.

file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (10 of 16) [2001-10-15 09:19:24]

[Appendix C] C.3 Zone File Records

C.3.1.5 Canonical Name record
The Canonical Name (CNAME) resource record defines an alias for the official name of a host. The
CNAME record provides a facility similar to nicknames in the host table. The facility provides
alternate host names for the convenience of users, and generic hostnames used by applications (such
as loghost used by syslogd).
The CNAME record is frequently used to ease the transition from an old hostname to a new hostname.
While it is best to avoid hostname changes by carefully choosing hostnames in the first place, not all
changes can be avoided. When you do make a name change, it can take a long time before it becomes
completely effective, particularly if the host name is embedded in a mailing list run at a remote site.
To reduce problems for the remote site, use a CNAME record until they can make the change.
The format of the CNAME record is:
nickname [ttl] IN CNAME host
nickname
This hostname is an alias for the official hostname defined in the host field. The nickname
can be any valid hostname.
ttl
Time-to-live is usually blank.
IN
The address class is IN.
CNAME
The Canonical Name resource record type is CNAME.
host
The canonical name of the host is provided here. This hostname must be the official hostname;
it cannot be an alias.
One important thing to remember about the CNAME record is that all other resource records must be
associated with the official hostname and not with the nickname. This means that the CNAME record
should not be placed between a host and the list of RRs associated with that host. The example below
shows a correctly placed CNAME record:
peanut

IN
IN
IN
IN

A
MX
HINFO
WKS

128.66.12.2
5 peanut.nuts.com.
SUN-3/60 "SUN OS 4.0"
129.6.16.2 TCP ftp telnet smtp domain

file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (11 of 16) [2001-10-15 09:19:24]

[Appendix C] C.3 Zone File Records

goober

IN
IN

WKS
CNAME

128.66.12.2 UDP domain
peanut.nuts.com.

In this example, the hostname peanut stays in force for the MX, HINFO, and WKS records because
they all have blank name fields. The CNAME record changes the name field value to goober, which is
a nickname for peanut. Any RRs with blank name fields following this CNAME record would
associate themselves with the nickname goober, which is illegal. An improper CNAME placement is:
peanut
goober

IN
IN
IN
IN
IN
IN

A
CNAME
MX
HINFO
WKS
WKS

128.66.12.2
peanut.nuts.com.
5 peanut.nuts.com.
SUN-3/60 "SUN OS 4.0"
128.66.12.2 TCP ftp telnet smtp domain
128.66.12.2 UDP domain

This improperly placed CNAME record causes named to display the error message "goober.nuts.com
has CNAME and other data (illegal)." Check /usr/adm/messages for named error messages to ensure
that you have not misplaced any CNAME records.
C.3.1.6 Domain Name Pointer record
The Domain Name Pointer (PTR) resource records are used to convert numeric IP addresses to
hostnames. This is the opposite of what is done by the address record that converts hostnames to
addresses. PTR records are used to construct the in-addr.arpa reverse domain files.
Many administrators ignore the reverse domains, because things appear to run fine without them.
Don't ignore them. Keep these zones up-to-date. Several programs use the reverse domains to map IP
addresses to hostnames when preparing status displays. A good example is the netstat command.
Some service providers - ftp.uu.net is the best example - use the reverse domains to track who is using
their service. If they cannot map your IP address back to a hostname, they reject your connection.
The format of the PTR record is:
name [ttl] IN PTR host
name
The name specified here is actually a number. The number is defined relative to the current inaddr.arpa domain. Names in an in-addr.arpa domain are IP addresses specified in reverse
order. If the current domain is 66.128.in-addr.arpa, then the name field for peanut
(128.66.12.2) is 2.12. These digits (2.12) are added to the current domain (66.128.inaddr.arpa) to make the name 2.12.66.128.in-addr.arpa. Chapter 4, Getting Started , discusses
the unique structure of in-addr.arpa domain names.
ttl

file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (12 of 16) [2001-10-15 09:19:24]