The Domain Database File

The domain database file contains most of the domain information. Its primary function is to convert hostnames to IP addresses so A records predominate, but this file contains all of the database records except PTR records. Creating the domain database file is both the most challenging and the most rewarding part of building a name server.

In the foobirds.org domain, wren is the master server. Based on the named.conf file shown in Listing 4.10, the domain database file is named foobirds.hosts. Its contents are shown in Listing 4.11.

Listing 4.11: A Sample DNS Zone File

; The foobirds.org domain database

$TTL 1w

@ IN SOA wren.foobirds.org. sara.wren.foobirds.org. ( 2002030601 ; Serial 21600 ; Refresh

Define the nameservers IN NS

IN NS

IN NS

Define the mail servers IN MX

IN MX

Retry Expire

Negative cache TTL

wren.foobirds.org.

falcon.foobirds.org.

bear.mammals.org.

10 wren.foobirds.org. 20 parrot.foobirds.org.

Define localhost localhost

Define the hosts in this zone wren parrot crow hawk falcon puffin robin redbreast www

CNAME CNAME CNAME

4 20 17

5 wren.foobirds.org. 172.16.5.2

5 wren.foobirds.org. robin.foobirds.org. wren.foobirds.org. parrot.foobirds.org.

Delegating subdomains terns

IN NS trumpeter.swans.foobirds.org.

IN NS parrot.foobirds.org.

IN NS arctic.terns.foobirds.org.

IN NS trumpeter.swans.foobirds.org.

Glue records for subdomain servers trumpeter.swans IN

arctic.terns IN

news

The SOA record All zone files begin with an SOA record. The @ in the name field of the SOA record refers to the current origin, which in this case is foobirds.org because that is the value defined in the zone statement of the configuration file. Because it ties the domain name back to the named configuration file, the name field of the SOA record is usually an at-sign.

The data field of the SOA record contains seven different components. It is so long, the data field of the SOA record normally spans several lines. The parentheses are continuation characters. After an opening parenthesis, all data on subsequent lines are considered part of the current record until a closing parenthesis. The components of the data field in the sample SOA record contain the following values:

wren.foobirds.org This is the hostname of the master server for this zone.

sara.wren.foobirds.org This is the e-mail address of the person responsible for this domain. Notice that the at-sign (@) normally used between the username (sara) and the hostname (wren.foobirds.org) in an e-mail address is replaced here with a dot (.).

2002030601 This is the serial number, a numeric value that tells the slave server that the zone file has been updated. To make this determination, the slave server periodically queries the master server for the SOA record. If the serial number in the master server's SOA record is greater than the serial number of the slave server's copy of the zone, the slave transfers the entire zone from the master. Otherwise, the slave assumes it has a current copy of the zone, and skips the zone transfer. The serial number should be increased every time the domain is updated in order to keep the slave servers synchronized with the master.

21600 This is the length of time in the refresh cycle. Every refresh cycle, the slave server checks the serial number of the SOA record from the master server to determine whether the zone needs to be transferred. The length of the refresh cycle can be defined using either a numeric or an alphanumeric format. (See the discussion of the $TTL directive for the details of these formats.) Listing 4.11 uses the numeric format to set the refresh cycle to 21,600 seconds, which tells the slave server to check four times per day. This indicates a stable database that does not change very frequently, which is often the case. Computers are added to the network periodically, but not usually on an hourly basis. When a new computer arrives, the hostname and address are assigned before the system is added to the network because the name and address are required to install and configure the system. Thus, the domain information is disseminated to the slave servers before users begin to query for the address of the new system. A low refresh cycle keeps the servers tightly synchronized, but a very low value is not usually required because the DNS NOTIFY message sent from the master server causes the slave to immediately check the serial number of the SOA record when an update occurs. The refresh cycle is a redundant backup for DNS NOTIFY.

1800 This is the retry cycle. The retry cycle defines the length of time that the slave server should wait before asking again when the master server fails to respond to a request for the SOA record. The length of time can be specified using either a numeric or an alphanumeric format. In this example, the numeric format is used to specify a retry time of 1800 seconds (30 minutes). Don't set the value too low—a half-hour or 15 minutes are good retry values. If the server doesn't respond, it may be down. Quickly retrying a down server gains nothing, and wastes network resources.

604800 This is the expiration time, which is the length of time that the slave server should continue to respond to queries, even if it cannot update the zone file. The idea is that at some point in time, out-of-date data are worse than no data. This should be a substantial amount of time. After all, the main purpose of a slave server is to provide backup for the master server. If the master server is down and the slave stops answering queries, the entire network is down instead of having just one server down. A disaster, such as a fire in the central computer facility, can take the master server down for a very long time. The time can be specified in either numeric or alphanumeric format. In Listing 4.10, 604,800 seconds (one week) is used; an equally common value is one month.

900 This is the default time-to-live that servers should use when caching negative information about this zone. All servers cache answers, and use those answers to respond to subsequent queries. Most of the answers cached by a server are standard resource records, which is positive information from the DNS database. A name server can also learn from the authoritative server for a zone that a specific piece of information does not exist, which is negative information. For example, the response to a query for bittern.foobirds.org would be that the domain name does not exist. This is valuable information that also should be cached. But with no associated resource record, and thus no explicit TTL, how long should it be cached? The negative cache TTL from the zone's SOA record tells remote servers how long to cache negative information. The SOA record in Listing 4.11 sets the negative cache value to 15 minutes (900 seconds). The negative cache TTL can be defined in either numeric or alphanumeric format. Use a negative cache of no more than 15 minutes—five minutes isn't bad either.

All of the components of the data field of the SOA record set values that affect the entire domain. Several of these items affect remote servers. You decide how often slave servers check for updates, and how long caching servers keep your data in their caches. The domain administrator is responsible for the design of the entire domain.

Defining the Name Servers In Listing 4.11, the NS records that follow the SOA record define the official name servers for the domain. Unless the also-notify option is used in the zone statement of the named.conf file, these are the only servers that receive a DNS NOTIFY message when the zone is updated.

Although they can appear anywhere in the file, the NS records often follow directly after the SOA record. When they do, the name field of each NS record can be blank. Because the name field is blank, the value of the last object named is used. In Listing 4.11, the last value to appear in the name field was the @ that referred to the foobirds.org domain defined in the named.conf file. Therefore, these NS records all define name servers for the foobirds.org domain.

The first two NS records point to the master server wren and the slave server falcon that we configured earlier. The third server is external to our network. Name servers should have good network connections, and slave name servers should have a path to the Internet that is independent from the path used by the master server. This enables the slave server to fulfill its purpose as a backup server, even when the network that the master server is connected to is down. Large organizations may have independent connections for both servers; small organizations usually do not. If possible, find a server that is external to your network to act as a slave server. Check with your Internet Service Provider (ISP); it may offer this as a service to its customers.

Defining the Mail Servers The first two MX records in Listing 4.11 define the mail servers for this domain. The name field is still blank, meaning that these records pertain to the last named object, which in this case is the entire domain. The first MX record says that wren is the mail server for the foobirds.org domain, with a preference of 10. If mail is addressed to [email protected], the mail is directed to wren for delivery.

The second MX record identifies parrot as a mail server for foobirds.org with a preference of 20. The lower the preference number, the more preferred the server. This means that mail addressed to the foobirds.org domain is first sent to wren. Only if wren is unavailable is the mail sent to parrot. parrot acts as a backup for those times when wren is down or offline.

These two MX records redirect mail addressed to the domain foobirds.org, but they do not redirect mail addressed to an individual host. Therefore, if mail is addressed to [email protected], it is delivered directly to hawk; it is not sent to a mail server. This configuration permits people to use e-mail addresses of the form [email protected] when they like, or to use direct delivery to an individual host when they want that. It is a very flexible configuration.

Some systems, however, may not be capable of handling direct delivery e-mail. An example is a Microsoft Windows system that doesn't run an SMTP mail program. Mail addressed to such a system would not be successfully delivered. To prevent this, assign an MX record to the individual host to redirect its mail to a valid mail server.

There are two examples of this in the sample zone file. Look at the resource records for puffin and robin. The address record of each system is followed by an MX record that directs mail to wren. The MX records have a blank name field, but this time they don't refer to the domain. In both cases, the last value in the name field is the name from the preceding address record. It is this name to which the MX record applies. In one case it is puffin, and in the other it is robin. With these records, mail addressed to [email protected] is delivered to [email protected].

The MX record is only the first step in creating a mail server. The MX is necessary to tell the remote computer where it should send the mail, but for the mail server to successfully deliver the mail to the intended user, it must be properly configured.

Note Chapter 5, "Configuring a Mail Server," looks at how sendmail is configured to properly handle the mail.

Defining the Host Information The bulk of the zone file consists of address records that map hostnames to IP addresses. The first address record in the domain database file in Listing 4.11 maps the name localhost.foobirds.org to the loopback address 127.0.0.1. The reason this entry is included in the database has something to do with the way that the resolver constructs queries. Remember that if a hostname contains no dots, the resolver extends it with the local domain. So when a user enters telnet localhost, the resolver sends the name server a query for localhost.foobirds.org. Without this entry in the database, the resolver would make multiple queries before finally finding localhost in the /etc/hosts file. The localhost entry is followed by several address entries for individual hosts in the domain.

The only other unexplained records in the section of Listing 4.11 that defines host information are the CNAME records. The first CNAME record says that redbreast is a hostname alias for robin. Aliases are used to map an obsolete name to a current name or to provide generic names such as www and news. Aliases cannot be used in other resource records. Therefore, take care when placing CNAME records in the domain database. You have seen several examples of the fact that a blank name field refers to the previously named object. If the CNAME record is placed improperly, a record with a blank name field can illegally reference a nickname.

For example, the file contains these records for robin:

robin IN A 172.16.5.2

IN MX 5 wren.foobirds.org.

redbreast IN CNAME robin.foobirds.org.

A mistake in placing these records could produce the following:

robin IN A 172.16.5.2

redbreast IN CNAME robin.foobirds.org.

IN MX 5 wren.foobirds.org.

This would cause named to display the error "redbreast.foobirds.com has CNAME and other data (illegal)" because the MX record now refers to redbreast. Due to the potential for errors, many domain administrators put the CNAME records together in one section of the file instead of intermingling them with other resource records.

Delegating a Subdomain The final six resource records in Listing 4.11 delegate the subdomains swans.foobirds.org and terns.foobirds.org. The root servers delegated the foobirds.org domain to us. We now have the authority to delegate any domains within the foobirds.org domain that we wish. In the example, two are delegated.

You have complete freedom to create subdomains and hostnames within your domain. Organizations create subdomains for two basic reasons:

• To simplify the management of a large number of hostnames. This reason is easy to understand; it is exactly why DNS was created in the first place. Delegating pieces of the domain spreads the burden of maintaining the system to more people and computers so that no one person or computer is overwhelmed with work.

• To recognize the structure within the organization. This reason springs from a fact of organizational life. Some parts of the organization will want to control their own services, no matter what. In Listing 4.11, two "organizational" subdomains are delegated—one to the group dedicated to research on swans and one to the group that works with terns.

Subdomains usually have either geographic or organizational names. denver.foobirds.org is an example of a geographic subdomain name while sales.foobirds.org is an example of an organizational name. One problem with naming a subdomain is that office locations change, and organizations reorganize. If the subdomain names you choose are too specific, you can bet that you will have to change them. Assume that your west coast office is in Santa Clara. You're better off naming the subdomain west or westcoast than you are calling it santaclara. If they move to a new building in San Jose, you don't want to have to change the subdomain name.

A domain does not officially exist until it is delegated by its parent domain. The administrator of trumpeter.swans.foobirds.org can configure the system as the master server for the swans domain, and enter all of the necessary domain data. It doesn't matter because no one will query the system for information about the domain. In fact, no computer in the outside world will even know that the swans domain exists. When you think of how the domain system works, you'll see why this is true.

The DNS system is a rooted hierarchical system. If a remote server has no information at all about the swans.foobirds.org domain, it asks a root server. The root server tells the remote server that wren and its slave servers know about foobirds.org. The remote server then asks wren. wren finds the answer to the query, either from its cache or by asking parrot or trumpeter, and replies with the answer along with the NS records for swans.foobirds.org and the IP addresses of trumpeter and parrot. Armed with the NS records and the IP addresses, the remote server can send other queries about the swans.foobirds.org domain directly to trumpeter.

The information path is from the root to wren and then to trumpeter. There is no way for the remote server to go directly to trumpeter or parrot for information until wren tells it where they are located. If the delegation did not exist in the foobirds.org domain, the path to the swans.foobirds.org domain would not exist.

Note Notice that the root server sends the remote server to wren, whereas wren looks up the answer for the remote server instead of just sending the remote server to trumpeter. The root servers are non-recursive servers: If they don't have an answer, they'll tell you who does, but they won't look it up for you. Most other servers are recursive servers: If they don't have the answer, they'll look it up for you.

The first four lines of the sample delegations are NS records.

terns swans

IN IN IN IN

NS NS NS NS

trumpeter.swans.foobirds.org. parrot.foobirds.org. arctic.terns.foobirds.org. trumpeter.swans.foobirds.org.

The first two records say that trumpeter and parrot are authoritative servers for the swans.foobirds.org domain. The last two records say that arctic and trumpeter are authoritative servers for the terns.foobirds.org domain.

Two other records are part of the subdomain delegation. They are address records:

Both of these addresses are for name servers located in domains that are subordinate to the current domain. These address records are called glue records because they help to link all of the domains together. In order to connect to a name server, you must have its address. If the address for arctic were only available from arctic, there'd be a problem. For this reason, the address of a name server located in a subordinate domain is placed in the parent domain when the subordinate domain is delegated.

Was this article helpful?

0 0

Post a comment