|
Chapter 8 Configuring DNS Name Service |
|
|
|
Chapter 8 Configuring DNS Name Service |
|
While the resolver configuration requires, at most, one configuration file, several files are used to configure named . The complete set of named configuration files are:
Sets general named parameters and points to the sources of domain database information used by this server. These sources can be local disk files or remote servers.
Points to the root domain servers
Used to locally resolve the loopback address
The zone file that maps hostnames to IP addresses
The zone file for the reverse domain that maps IP addresses to hostnames
The filenames shown here are generic names. We use them to make it easier to discuss the files in this text. The files can have any names you wish. Use the filenames named.boot and named.local for the boot file and the loopback address file. Use the name named.ca or one of the well-known alternatives, named.root and root.ca , for the file that lists the root servers. However, don't use the names named.hosts and named.rev for your zone files. Use descriptive names. In the following sections, we'll look at how each of these files is used, starting with named.boot .
The named.boot file points named to sources of DNS information. Some of these sources are local files; others are remote servers. You only need to create the files referenced in the primary and cache statements. We'll look at an example of each type of file you may need to create.
Table 8.1 summarizes the named.boot configuration statements used in this chapter. It provides just enough information to help you understand the examples. Not all of the named.boot configuration commands are used in the examples, and you probably won't use all of the commands in your configuration. The commands are designed to cover the full spectrum of configurations, even the configurations of root servers. If you want more details about all of the named.boot configuration statements, Appendix C contains a full explanation of each command.
| Command | Function |
|---|---|
| directory | Defines a directory for all subsequent file references |
| primary | Declares this server as primary for the specified zone |
| secondary | Declares this server as secondary for the specified zone |
| cache | Points to the cache file |
| forwarders | Lists servers to which queries are forwarded |
| options | Enables optional BIND processing |
| xfrnets | Limits zone transfers to specific addresses |
The way in which you configure the named.boot file controls whether the nameserver acts as a primary server, a secondary server, or a caching-only server. The best way to understand these different configurations is to look at sample named.boot files. The next sections show examples of each type of configuration.
A caching-only server configuration is simple. A named.boot file and a named.ca file are all that you need, though the named.local file is usually also used. The most common named.boot file for a caching-only server is:
; ; a caching-only server configuration ; primary 0.0.127.IN-ADDR.ARPA /etc/named.local cache . /etc/named.ca
The only line in this sample file required for a caching-only configuration is the cache statement. It tells named to maintain a cache of nameserver responses, and to initialize the cache with the list of root servers found in the file named.ca . The name of the file containing the root server list can be any name you wish, but root.cache , named.root , and named.ca are often used. The presence of a cache statement does not make this a caching-only configuration; a cache statement is used in every server configuration. It is the absence of primary and secondary statements that makes this a caching-only configuration.
However, there is one primary statement that is an exception to this rule. You'll see it in our sample named.boot file, and in almost every caching-only configuration. It defines the local server as the primary server for its own loopback domain, and it says that the information for the loopback domain is stored in the file named.local . The loopback domain is an in-addr.arpa domain [5] that maps the address 127.0.0.1 to the name localhost . The idea of resolving your own loopback address makes sense to most people, so most named.boot files contain this entry.
[5] See Chapter 4, Getting Started , for a description of in-addr.arpa domains.
These primary and cache statements are the only statements used in most caching-only server configurations, but other statements can be added. A forwarders statement, and even an options statement are sometimes used. The forwarders statement causes the caching-only server to send all of the queries that it cannot resolve from its own cache to specific servers. For example:
forwarders 172.16.12.1 172.16.1.2
This statement forwards every query that cannot be answered from the local cache to 172.16.12.1 and 172.16.1.2. The forwarders command builds a rich DNS cache on selected servers located on the local network. This reduces the number of times that queries must be sent out on the wide area network, which is particularly useful if you have limited bandwidth to the wide area network or if you are charged for usage.
When network access to the outside world is severely limited, use the following statement to force the local server to always use the forwarder.
options forward-only
With this statement in the configuration file, the local server will not attempt to resolve a query itself even if it cannot get an answer to that query from the forwarders.
Adding forwarders or options statements does not change this from being a caching-only server configuration. Only the addition of primary and secondary commands will do that.
The imaginary nuts.com domain is the basis for our sample primary and secondary server configurations. Here is the named.boot file to define almond as the primary server for the nuts.com domain:
; ; nuts.com primary nameserver boot file. ; directory /etc primary nuts.com named.hosts primary 16.172.IN-ADDR.ARPA named.rev primary 0.0.127.IN-ADDR.ARPA named.local cache . named.ca
The directory statement saves keystrokes on the subsequent filenames. It tells named that all relative filenames (i.e., filenames that don't begin with a /), no matter where they occur in the named configuration, are relative to the directory /etc .
The first primary statement declares that this is the primary server for the nuts.com domain, and that the data for that domain is loaded from the file named.hosts . In our examples, we'll use the filename named.hosts as the zone filename, but you should choose a more descriptive filename. For example, a better name for the nuts.com zone file is nuts.com.hosts .
The second primary statement points to the file that maps IP addresses from 172.16.0.0 to hostnames. This statement says that the local server is the primary server for the reverse domain 16.172.in-addr.arpa , and that the data for that domain is loaded from the file named.rev . Again, the filename named.rev is just an example; use descriptive names in your actual configuration.
The format of a primary statement is the keyword
primary
, the domain name, and the name of the zone file from which the domain information is read. All primary statements have this simple format.
The final two statements in the sample configuration are the primary statement for the loopback domain and the cache statement. These statements are discussed earlier in the section about caching-only configurations. They have the same function in every configuration and are found in almost every configuration.
A secondary server's configuration differs from a primary's by using
secondary
instead of
primary
statements. Secondary statements point to remote servers as the source of the domain information instead of local disk files. Secondary statements begin with the keyword
secondary
, followed by the name of the domain, the address of one or more authoritative servers for that domain, and finally the name of a local file where information received from the remote server will be stored. The following
named.boot
file configures
filbert
as a secondary server for the
nuts.com
domain:
; ; nuts.com secondary nameserver boot file. ; directory /etc secondary nuts.com 172.16.12.1 nuts.com.hosts secondary 16.172.IN-ADDR.ARPA 172.16.12.1 172.16.rev primary 0.0.127.IN-ADDR.ARPA named.local cache . named.ca
The first secondary statement makes this a secondary server for the nuts.com domain. The statement tells named to download the data for the nuts.com domain from the server at IP address 172.16.12.1, and to store that data in the file /etc/nuts.com.hosts . If the nuts.com.hosts file does not exist, named creates it, gets the zone data from the remote server, and writes the data in the newly created file. If the file does exist, named checks with the remote server to see if the remote server's data is different from the data in the file. If the data has changed, named downloads the updated data and overwrites the file contents with the new data. If the data has not changed, named loads the contents of the disk file and doesn't bother with a zone transfer. [6] Keeping a copy of the database on a local disk file makes it unnecessary to transfer the zone file every time the local host is rebooted. It's only necessary to transfer the zone when the data changes.
[6] Appendix C (in the SOA record section) discusses how named determines if data has been updated.
The next line in this configuration says that the local server is also a secondary server for the reverse domain 16.172.in-addr.arpa , and that the data for that domain should also be downloaded from 172.16.12.1. The reverse domain data is stored locally in a file named 172.16.rev , following the same rules discussed previously for creating and overwriting nuts.com.hosts .
The configuration commands discussed above and listed in Table 8.1 are used only in the named.boot file. All other files used to configure named ( named.hosts , named.rev , named.local , and named.ca ) store domain database information. These files all have the same basic format and use the same type of database records. They use standard resource records, called RRs. These are defined in RFC 1033, the Domain Administrators Operations Guide , and other RFCs. Table 8.2 summarizes all of the standard resource records used in this chapter. These records are covered in detail in Appendix C .
| Resource Record | Record | Function |
|---|---|---|
| Text Name | Type | |
| Start of Authority | SOA |
Marks the beginning of a zone's data, and defines parameters that affect the entire zone. |
| Nameserver | NS | Identifies a domain's nameserver. |
| Address | A | Converts a hostname to an address. |
| Pointer | PTR | Converts an address to a hostname. |
| Mail Exchange | MX | Identifies where to deliver mail for a given domain name. |
| Canonical Name | CNAME | Defines an alias hostname. |
| Host Information | HINFO | Describes a host's hardware and OS. |
| Well-Known Service | WKS | Advertises network services. |
| Text | TXT | Stores arbitrary text strings. |
The resource record syntax is described in Appendix C , but a little understanding of the structure of these records is necessary to read the sample configuration files used in this chapter.
The format of DNS resource records is:
[
name
] [
ttl
]
IN
type data
name
This is the name of the domain object the resource record references. It can be an individual host or an entire domain. The string entered for the
name
field is relative to the current domain unless it ends with a dot. If the name field is blank, the record applies to the domain object that was named last. For example, if the A record for
peanut
is followed by an MX record
with a blank
name
field, both the A record and the MX record apply to
peanut
.
ttl
Time-to-live defines the length of time, in seconds, that the information in this resource record should be kept in a remote system's cache. Usually this field is left blank and the default
ttl
, set for the entire zone in the SOA record,
is used. [7]
[7] See the section on SOA records in Appendix C .
Identifies the record as an Internet DNS resource record. There are other classes of records, but they are rarely used. Curious? See Appendix C for the other, non-Internet, classes.
type
Identifies the kind of resource record.
Table 8.2
lists the record types under the heading "Record Type." Specify one of these values in the
type
field.
data
The information specific to this type of resource record. For example, in an A record this is the field that contains the actual IP address.
In the following sections we look at each of the remaining configuration files. As you look at the files, remember that all of the records in these files are standard resource records that follow the format described above.
The cache statement in named.boot points to a cache initialization file. Each server that maintains a cache has such a file. It contains the information needed to begin building a cache of domain data when the nameserver starts. The root domain is indicated on the cache statement by a single dot, and the named.ca file contains the names and addresses of the root servers.
The named.ca file is sometimes called a "hints" file, because it contains hints named uses to initialize the cache. The hints it contains are the names and addresses of the root servers. It is used to help the local server locate a root server during startup. Once a root server is found, an authoritative list of root servers is downloaded from that server. The hints are not referred to again until the local server is forced to restart. The information in the named.ca file is not referred to often, but it is critical for booting a named server.
The basic named.ca file contains NS records that name the root servers, and A records that provide the addresses of the root servers. A sample named.ca file is shown below:
; . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 IN A 128.9.0.107 ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 ; . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 ; . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 ; . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 ; . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17
This file contains only nameserver and address records. Each NS record identifies a nameserver for the root (
.
) domain. The associated A record gives the address of each root server. The ttl value for all of these records is 3600000 - a very large value that is approximately 42 days.
Create the named.ca file by downloading the file domain/named.root from rs.internic.net (198.41.0.7) via anonymous ftp . The file stored at the InterNIC is in the correct format for a UNIX system. The example below shows the superuser downloading the named.root file directly into the local system's named.ca file. The file doesn't even need to be edited: it is ready to run.
# ftp rs.internic.net Connected to rs.internic.net. Name (rs.internic.net:craig): anonymous 331 Guest login ok, send your email address as password. Password: [email protected] 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> get domain/named.root named.ca 200 PORT command successful. 150 Opening data connection for domain/named.root (2119 bytes). 226 Transfer complete. 2119 bytes received in 0.137 secs (15 Kbytes/sec) ftp> quit 221 Goodbye.
Download the named.root file every few months to keep accurate root server information in your cache. A bogus root server entry could cause problems with your local server. The data given above is correct as of publication, but could change at any time.
If your system is not connected to the Internet, it won't be able to communicate with the root servers. Initializing your cache file with the servers listed above would be useless. In this case, initialize your cache with entries that point to the major nameservers on your local network. Those servers must also be configured to answer queries for the "root" domain. However, this root domain contains only NS records pointing to the domain servers on your local network. For example: assume that nuts.com is not connected to the Internet and that almond and pecan are going to act as root servers for this isolated domain. Both servers declare they are primary for the root domain in their named.boot files. They load the root from a zone file that contains NS records and A records, stating that they are authoritative for the root and delegating the nuts.com and 16.172.in-addr.arpa domains to the local nameservers that service those domains. (How domains are delegated is covered later in the chapter.) Details of this type of configuration are provided in DNS and BIND by Liu and Albitz (O'Reilly & Associates).
The named.local file is used to convert the address 127.0.0.1 (the "loopback address") into the name localhost . It's the zone file for the reverse domain 0.0.127.IN-ADDR.ARPA. Because all systems use 127.0.0.1 as the "loopback" address, this file is virtually identical on every server. Here's a sample named.local file:
@ IN SOA almond.nuts.com. jan.almond.nuts.com. ( 1 ; serial 360000 ; refresh every 100 hours 3600 ; retry after 1 hour 3600000 ; expire after 1000 hours 360000 ; default ttl is 100 hours ) IN NS almond.nuts.com. 0 IN PTR loopback. 1 IN PTR localhost.
Neither the NS record nor the first PTR record is required. The first PTR record maps the network 127.0.0.0 to the name loopback , which is an alternative to mapping the network name in the /etc/networks file. Only the SOA record and the second PTR record are needed. The required PTR record is the same on every host: host address 1 on network 127.0.0 is mapped to the name localhost .
The SOA record's data fields and the NS record that contains the computer's hostname vary from system to system. The sample SOA record identifies almond.nuts.com. as the server originating this zone, and the email address jan.almond.nuts.com. as the point of contact for any questions about the zone. (Note that in an SOA record the email address is written with a dot separating the recipient's name from the hostname: jan is the user and almond.nuts.com is the host.) Many systems do not include the NS record; but when it is used, it contains the computer's hostname. Change these three data fields and you can use this identical file on any host.
The files discussed so far, named.boot , named.ca , and named.local , are the only files required to configure caching-only servers and secondary servers. Most of your servers will use only these files, and the files used will contain almost identical information on every server.
The simplest way to create these three files is to copy a sample file and modify it for your system. Most systems come with sample files. If your system doesn't, sample configuration files are available in the conf/master directory [8] of the bind.tar.gz file. This compressed tar file can be obtained via anonymous ftp from the isc/bind/src directory on ftp.isc.org . The named.local file shown above was derived from the named.local sample that comes with BIND.
[8] The sample named.ca file in this directory is called root.cache .
The remaining named configuration files, named.hosts and named.rev , are more complex, but the relative number of systems that require these files is small. Only the primary server needs all of the configuration files, and there should be only one primary server per zone.
The named.rev file is very similar in structure to the named.local file. Both of these files translate IP addresses into hostnames, so both files contain PTR records.
The named.rev file in our example is the zone file for the 16.172.in-addr.arpa domain. The domain administrator creates this file on almond , and every other host that needs this information gets it from there.
; ; Address to hostname mappings. ; @ IN SOA almond.nuts.com. jan.almond.nuts.com. ( 10099 ; Serial 43200 ; Refresh 3600 ; Retry 3600000 ; Expire 2592000 ) ; Minimum IN NS almond.nuts.com. IN NS filbert.nuts.com. IN NS foo.army.mil. 1.12 IN PTR almond.nuts.com. 2.12 IN PTR peanut.nuts.com. 3.12 IN PTR pecan.nuts.com. 4.12 IN PTR walnut.nuts.com. 2.1 IN PTR filbert.nuts.com. 6 IN NS salt.plant.nuts.com. IN NS pecan.nuts.com.
Like all zone files, the
named.rev
file begins with an SOA record.
The
@
in the name field of the SOA record references the current domain. In this case it is the domain defined by the primary statement in our sample
named.boot
file:
primary 16.172.IN-ADDR.ARPA named.rev
The
@
in the SOA record allows the primary statement to define the zone file domain. This same SOA record is used on every zone; it always references the correct domain name because it references the domain defined for that particular zone file in
named.boot
. Change the hostname (
almond.nuts.com.
) and the manager's mail address (
jan.almond.nuts.com.
), and use this SOA record in any of your zone files.
The NS records that follow the SOA record define the nameservers for the domain. Generally the nameservers are listed immediately after the SOA, before any other record has the chance to modify the domain name. Recall that a blank name field means that the last domain name is still in force. The SOA's domain reference is still in force because the following NS records have blank name fields.
PTR records dominate the named.rev file because they are used to translate addresses to hostnames. The PTR records in our example provide address-to-name conversions for hosts 12.1, 12.2, 12.3, 12.4, and 2.1 on network 172.16. Because they don't end in dots, the values in the name fields of these PTR records are relative to the current domain. For example, the value 3.12 is interpreted as 3.12.16.172.in-addr.arpa. The host name in the data field of the PTR record is fully qualified to prevent it from being relative to the current domain name. Using the information in this PTR, named will translate 3.12.16.172.in-addr.arpa into pecan.nuts.com.
The last two lines of this file are additional NS records. As with any domain, subdomains can be created in an in-addr.arpa domain. This is what the last two NS records do. These NS records point to pecan and salt as nameservers for the subdomain 6.16.172.in-addr.arpa . Any query for information in the 6.16.172.in-addr.arpa subdomain is referred to them. NS records that point to the servers for a subdomain must be placed in the higher-level domain before you can use that subdomain.
Subdomains in the in-addr.arpa domain are not as common or as useful as subdomains in the host namespace. Domain names and IP addresses are not the same thing, and do not have the same structure. When an IP address is turned into an in-addr.arpa domain name, the four bytes of the address are treated as four distinct pieces. In reality, the IP address is 32 contiguous bits. Subnets divide up the IP address space and subnet masks are bit-oriented, which does not limit them to byte boundaries. in-addr.arpa subdomains divide up the domain name space and can only occur at a full byte boundary because each byte of the address is treated as a distinct "name."
The named.hosts file contains most of the domain information. This file converts hostnames to IP addresses, so A records predominate; but it also contains MX, CNAME, and other records. The named.hosts file, like the named.rev file, is only created on the primary server. All others servers get this information from the primary server.
; ; Addresses and other host information. ; @ IN SOA almond.nuts.com. jan.almond.nuts.com. ( 10118 ; Serial 43200 ; Refresh 3600 ; Retry 3600000 ; Expire 2592000 ) ; Minimum ; Define the nameservers and the mail servers IN NS almond.nuts.com. IN NS filbert.nuts.com. IN NS foo.army.mil. IN MX 10 almond.nuts.com. IN MX 20 pecan.nuts.com. ; ; Define localhost ; localhost IN A 127.0.0.1 ; ; Define the hosts in this zone ; almond IN A 172.16.12.1 IN MX 5 almond.nuts.com. loghost IN CNAME almond.nuts.com. peanut IN A 172.16.12.2 IN MX 5 almond.nuts.com. goober IN CNAME peanut.nuts.com. pecan IN A 172.16.12.3 walnut IN A 172.16.12.4 filbert IN A 172.16.1.2 ; host table has BOTH host and gateway entries for 10.104.0.19 mil-gw IN A 10.104.0.19 ; ; Glue records for servers within this domain ; pack.plant IN A 172.16.18.15 acorn.sales IN A 172.16.6.1 ; ; Define sub-domains ; plant IN NS pack.plant.nuts.com. IN NS pecan.nuts.com. sales IN NS acorn.sales.nuts.com. IN NS pack.plant.nuts.com.
Like the named.rev file, the named.hosts file begins with an SOA record and a few NS records that define the domain and its servers, but the named.hosts file contains a wider variety of resource records than a named.rev file does. We'll look at each of these records in the order in which they occur in the sample file, so that you can follow along using the sample file as your reference.
The first MX record identifies a mail server for the entire domain. This record says that almond is the mail server for nuts.com with a preference of 10. Mail addressed to [email protected] is redirected to almond for delivery. Of course for almond to successfully deliver the mail, it must be properly configured as a mail server. The MX record is only part of the story. We look at configuring sendmail in Chapter 10, sendmail .
The second MX record identifies pecan as a mail server for nuts.com with a preference of 20. Preference numbers let you define alternate mail servers. The lower the preference number, the more desirable the server. Therefore, our two sample MX records say "send mail for the nuts.com domain to almond first; if almond is unavailable, try sending the mail to pecan ." Rather than relying on a single mail server, preference numbers allow you to create backup servers. If the main mail server is unreachable, the domain's mail is sent to one of the backups instead.
These sample MX records redirect mail addressed to nuts.com , but mail addressed to [email protected] will still be sent directly to walnut.nuts.com - not to almond or pecan . This configuration allows simplified mail addressing in the form user@ nuts.com for those who want to take advantage of it, but it continues to allow direct mail delivery to individual hosts for those who wish to take advantage of that.
The first A record in this example defines the address for localhost . This is the opposite of the PTR entry in the named.local file. It allows users within the nuts.com domain to enter the name localhost and have it resolved to the address 127.0.0.1 by the local nameserver.
The next A record defines the IP address for almond . (Note that the records that relate to a single host are grouped together, which is the most common structure used in zone files.) The A record is followed by an MX record and a CNAME record that both relate to almond . The almond MX record points back to the host itself, and the CNAME record defines an alias for the host name.
This host-specific MX record is provided as a courtesy to remote mailers. Some mailer implementations look for an MX record first, and then query for the host's address. Providing an MX record saves these mailers one additional nameserver query.
peanut 's A record is also followed by an MX record and a CNAME record. However, peanut 's MX record serves a different purpose. It directs all mail addressed to [email protected] to almond . This MX record is required because the MX records at the beginning of the zone file redirect mail only if it is addressed to [email protected] . If you also want to redirect mail addressed to peanut , you need a "peanut-specific" MX record.
The name field of the CNAME record contains an alias for the official hostname. The official name, called the canonical name, is provided in the data field of the record. Because of these records, almond can be referred to by the name loghost , and peanut can be referred to as goober . The loghost alias is a generic hostname used to direct syslogd output to almond . [9] Hostname aliases should not be used in other resource records. [10] For example, don't use an alias as the name of a mail server in an MX record. Use only the "canonical" (official) name that's defined in an A record.
[9] See Chapter 3 for a further discussion of generic hostnames.
[10] See Appendix C for additional information about using CNAME records in the named.hosts file.
Your named.hosts file will be much larger than the sample file we've discussed, but it will contain essentially the same records. If you know the names and addresses of the hosts in your domain, you have most of the information necessary to create the named configuration.
After you construct the named.boot file and the required zone files, start named . named is usually started at boot time from a startup script, but it can be started at the command prompt:
#named
The first time you run it, watch for error messages. named logs errors to the messages file. [11] Once named is running to your satisfaction, use nslookup to query the nameserver to make sure it is providing the correct information.
[11] This file if found at /usr/adm/messages on both our Linux and Solaris sample systems but it might be located somewhere else on your system. Check your system's documentation.
|
|
|
|
| 8.2 Configuring the Resolver |
|
8.4 Using nslookup |