|
Appendix C A named Reference |
|
|
|
Appendix C A named Reference |
|
Two types of entries are used to construct a zone file: control entries that simplify constructing the file, and standard resource records that define the domain data contained in the zone file. While there are several types of standard resource records, there are only two control statements. These are:
filename
Identifies a file that contains data to be included in the zone file. The data in the included file must be valid control entries or standard resource records. $INCLUDE allows a large zone file to be divided into smaller, more manageable units.
The
filename
specified on the command line is relative to the directory named on the directory statement in the
named.boot
file. For example: if the
named.boot
file for
almond
contains a
directory /etc
statement, and a zone file on
almond
contains an
$INCLUDE sales.hosts
statement, then the file
/etc/sales.hosts
would be included in that zone file. If you don't want the filename to be relative to that directory, specify a fully qualified name, such as
/usr/dns/sales.hosts
.
domainname
Changes the default domain name used by subsequent records in the zone file. Use this command to put more than one domain in a zone file. For example, an $ORIGIN sales statement in the nuts.com zone file sets the domain name to sales.nuts.com . All subsequent resource records would be relative to this new domain.
The named software uses $ORIGIN statements to organize its own information. Dumping the named database, with the SIGINT signal, produces a single file containing all the information that the server knows. This file, named_dump.db , contains many $ORIGIN entries used to place all of the domains that named knows about into a single file.
These two control entries are helpful for organizing and controlling the data in a zone file, but all of the actual database information comes from standard resource records. All of the files pointed to by named.boot contribute to the DNS database, so all of these files are constructed from 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
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.
The same general resource record format is used for each of the resource records in a zone file. Each resource record is described below.
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 SOAorigin 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.
The address class is IN for all Internet RRs.
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
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 [email protected] 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 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.
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 [email protected] . 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.
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.
The address class is IN.
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.
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.
The address class is IN.
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 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."
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.
The address class is IN.
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 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 Internet-style 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 non-connected 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 [email protected] 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
.
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.
The address class is IN.
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 A 128.66.12.2 IN MX 5 peanut.nuts.com. IN HINFO SUN-3/60 "SUN OS 4.0" IN WKS 129.6.16.2 TCP ftp telnet smtp domain IN WKS 128.66.12.2 UDP domain goober IN CNAME 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 IN A 128.66.12.2 goober IN CNAME peanut.nuts.com. IN MX 5 peanut.nuts.com. IN HINFO SUN-3/60 "SUN OS 4.0" IN WKS 128.66.12.2 TCP ftp telnet smtp domain IN WKS 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.
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
in-addr.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.in-addr.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
Time-to-live is usually blank.
The address class is IN.
The Domain Name Pointer resource record type is PTR.
host
This is the fully qualified domain name of the computer whose address is specified in the name field. The host must be specified as a fully qualified name because the name cannot be relative to the current in-addr.arpa domain.
There are many examples of PTR records in the sample named.rev file shown in Chapter 8 .
The Host Information (HINFO) resource record provides a short description of the hardware and operating system used by a specific host. The hardware and software are described using standard terminology defined in the Assigned Numbers RFC in the sections on Machine Names (hardware) and System Names (software). There are a large number of hardware and software designators listed in the RFC. Most name use the same general format. Names with embedded blanks must be enclosed in quotes, so some names have a dash (-) where you might expect a blank. A machine name is usually the manufacturer's name in uppercase letters separated from the model number by a dash; e.g., IBM-PC/AT or SUN-3/60. The system name is usually the manufacturer's operating system name written in uppercase letters; e.g., DOS or "SUN OS 4.0." Naturally the rapid changes in the computer market constantly make the data in the Assigned Numbers RFC out-of-date. Because of this, many administrators make up their own values for machine names and system names.
The format of the HINFO record is:
[
host
] [
ttl
]
IN HINFO
hardware software
host
The hostname of the computer whose hardware and software is described in the data section of this resource record.
ttl
Time-to-live is usually blank.
The address class is IN.
HINFO is the resource record type. All of the information that follows is part of the HINFO data field.
hardware
This field identifies the hardware used by this host. It contains the machine name defined in the Assigned Numbers RFC. This field must be enclosed in quotes if it contains any blanks. A single blank space separates the hardware field from the software field that follows it.
software
This field identifies the operating system software this host runs. It contains the system name defined for this operating system in the Assigned Numbers RFC. Use quotes if the system name contains any blanks.
No widely used application makes use of the HINFO record; the record just provides information. Some security-conscious sites discourage its use. They fear that this additional information helps intruders narrow their attacks to the specific hardware and operating system that they wish to crack.
The Well-Known Services (WKS) resource record names the network services supported by the specified host. The official protocol names and services names used on the WKS record are defined in the Assigned Numbers RFC. The simplest way to list the names of the well-known services is to cat the /etc/services file on your system. Each host can have no more than two WKS records; one record for TCP and one for UDP. Because several services are usually listed on the WKS record, each record may extend through multiple lines.
The format of the WKS record is:
[
host
] [
ttl
]
IN WKS
address protocol services
host
The hostname of the computer that provides the advertised services.
ttl
Time-to-live is usually blank.
The address class is IN.
The resource record type is WKS. All of the information that follows is variable information for the WKS record.
address
The IP address of the host written in dotted decimal format, e.g., 128.66.12.2.
protocol
The transport level protocol through which the service communicates - either TCP or UDP.
services
The list of services provided by this host. As few or as many services as you choose may be advertised, but the names used to advertise the services must be the names found in the /etc/services file. Items in the list of services are separated by spaces. Parentheses are used to continue the list beyond a single line.
There are no widely used applications that make use of this record. It is only used to provide general information about the system. Again, security-conscious sites may not wish to advertise all of their services. Some protocols, such as tftp and finger , are prime targets for intruders.
The Text (TXT) resource record holds string data. The text data can be in any format. There are no standard TCP/IP applications for processing TXT records. These records are used to provide free-form information about the named object. Some sites create local processes for TXT records and define a local format for the information. For example, a TXT record could hold the Ethernet address of a host at one site and a room number at another site.
The format of the TXT record is:
[
name
] [
ttl
]
IN TXT
string
|
|
|
|
| C.2 named.boot Configuration Commands |
|
D. A dhcpd Reference |