Essential System Administration, Third Edition

The Domain Name System (DNS) is the facility that provides name resolution services.^[1] This service consists of two distinct activities: the actual hostname-to-IP address translation process and distribution mechanisms for the underlying translation data. Structurally, DNS is a distributed database whose contents are spread across the entire Internet, with individual DNS servers permanently storing only the subset of data for which they are responsible. Queries into this massively distributed database work because DNS has the ability to forward translation requests to the appropriate server automatically, in a manner that scales extremely well. The total amount of DNS data is also referred to as theDNS namespace.

^[1] Actually, to be rigorously technically correct, DNS is the specification for name resolution services. On Unix systems, the actual implementation is called the Berkeley Internet Name Domain (BIND). Other systems, such as Windows NT and its successors, call the implementation DNS as well, conflating this distinction. Unix parlance also frequently uses the designation "DNS" for both the specification and the implementation, as I've done in the text above.

The DNS organizational structure defines thedomain name hierarchy familiar to most Internet users (see Figure 8-1). Domain names are arranged within a tree structure rooted at the root domain, which is designated by a single dot: ".". Underneath the root domain are a series of top-level domains (TLDs) whose names take one of two forms: generic suffixes loosely indicating organization type (gTLDs) or two-character country codes (ccTLDs). The currently defined generic TLDs are summarized in Table 8-1 (see http://www.icann.org/tlds/ for up-to-the-minute information).

Examples of country code TLDs include .us (USA),^[2] .uk (United Kingdom), .jp (Japan), .fr (France), .it (Italy), .de (Germany), .at (Austria), .es (Spain), .ar (Argentina), .mx (Mexico), .fi (Finland), .cn (China), .pl (Poland) and .au (Australia). As these examples indicate, the country code can derive from either the English or native-language country name (e.g., Japan/.jp versus España/.es). See http://www.iana.org/cctld/cctld-whois.htm for a full list of country code TLDs.

^[2] Formerly reserved for state, regional, local, primary and secondary educational and other public entities, second-level .us subdomains are now available to U.S. citizens and U.S.-based organizations.

Some of these TLDs are further subdivided before organization-specific domain names are assigned, creating generic second-level domains.^[3] For example, the .uk ccTLD includes the co.uk, ac.uk and nhs.uk subdomains for commercial, academic, and National Health Service organizations, respectively (as well as many others; http://www.ilrt.bris.ac.uk/people/cmdjb/projects/uksites/uk-domains.html has all the gory details).

^[3] You can also say that co.uk and the others are subdomains of the TLD .uk. In fact, all domains are subdomains, because even TLDs are subdomains of the root domain.

Consult http://www.alldomains.com/alltlds.html for a list of second-level domains by country code. These domains are sometimes subdivided by the national authority. For example, scot.nhs.uk is the domain for theNational Health Service in Scotland, and organizations within it are assigned fourth-level domain names (e.g., the Scotland Anti-Smoking Council a fictitious organization might be smoke-free.scot.nhs.uk).

To obtain your own domain, you must register with the proper authority for the TLD in which you want your domain to be located. See the following websites for lists of accredited registrars:

gTLDs

http://www.icann.org/registrars/accredited-list.html

ccTLDs

Follow the "URL for registration services" link on the appropriate http://www.iana.org/root-whois/cc.htm page (where cc is the country code). Note that some countries also have other registrars, but you'll probably have to do a web search to find them.

.us subdomains

http://www.nic.us

Once an organization has obtained a domain name, it can subdivide it further if that makes sense. For example, as illustrated in Figure 8-1, ahania.com is divided into two subdomains organized by geographical location, and the usa.ahania.com subdomain is subdivided based on organizational function. Each level of a domain can contain both host records and subdomains.

If you follow a branch of the domain tree long enough, you will eventually reach actual hosts. In Figure 8-1, the hosts ns.smoke-free.scot.nhs.uk and webhost.mktg.usa.ahania.com both reside in fourth-level domains within the overall tree. However, the former is located at the top level of its specific domain, smoke-free.scot.nhs.uk, while the latter is within a third-level subdomain of ahania.com. Structurally, havoc.evil-ones.net is similar to ns.smoke-free.scot.nhs.uk in that it also is located at the top of its domain, evil-ones.com. We will consider other items within this illustration at various points within this section.

NOTE

Domain names are not case-sensitive. Each subdomain component is limited to 63 characters. A fully qualified hostname is limited to 255 characters. Second-level domain names are recommended to be 12 characters or less. Name characters are limited to letters, numbers, and hyphens. The first and last characters cannot be hyphens. Everybody prefers shorter names to longer ones (less typing).

DNS implementations, including the Unix Berkeley Internet Name Domain (BIND), include the following components:

The resolver

A subroutine library used by commands and user programs (specifically, gethostbyname and its relatives). We discussed resolver configuration in Section 5.2.

The name server

On Unix systems, this is the daemon named. This server is configured via a collection of ASCII configuration files. (The daemon's name is pronounced "name-D.")

8.1.1 Zones

Name servers provide name resolution services for a DNS zone. A zone is the name given to the collection of hosts within a domain, excluding any subdomains. For example, in Figure 8-1, the ahania.com zone consists of all the hosts within ahania.com itself, but not those within any of its subdomains or their children. If each subdomain has its own authoritative name server (defined below), the ahania.com domain would contain five (forward) zones: ahania.com, usa.ahania.com, asia.ahania.com, admin.usa.ahania.com, and mktg.usa.ahania.com.

Some zone files hold records that map hostnames to IP address and are used for DNS queries. Others define reverse lookup zones and are used to perform the opposite query: mapping an IP address to a host name. Reverse lookup zones are assigned names of the form c.b.a.in-addr.arpa where c, b, and a are the third, second, and first components of local network address, respectively. For example, 10.168.192.in-addr.arpa is the reverse lookup zone for the 192.168.10 subnet. The order of numbers within the network address is reversed in the reverse lookup zone name. The first component, c, is omitted when it is not used for the network part of IP addresses: e.g., 1.10.in-addr.arpa is the reverse lookup zone for the 10.1 subnet.

Every forward zone has at least one corresponding reverse lookup zone. Thus, the ahania.com domain in Figure 8-1 would also contain five reverse lookup zones (although their names are not evident from the illustration). The figure does include one reverse lookup zone for illustrative purposes.

8.1.2 Name Server Types

Name servers can operate in many different ways:

• They can perform recursive or nonrecursive searches in response to queries. Suppose server tom has the answer to a query, but you ask server bill (who doesn't know the answer). In a recursive query, bill will ask tom for you and then return the answer to you. In a nonrecursive query, bill will reply that he doesn't know and tell you to ask tom next. Most Unix clients expect name servers to perform recursive queries, and this is their default mode.

• They can return authoritative or nonauthoritative answers to a query. Authoritative answers are returned by servers that are designated as the holders of a specific set of data (see below). Nonauthoritative responses come from servers that happen to know the required information as a result of a prior query. Name servers generally retain information they have learned in their cache for a period of time (after which it is discarded). The cache is also reinitialized every time the server is restarted. In the BIND versions we are considering, negative query responses are also cached, meaning the name server keeps track of names that it could not resolve and does not try again until the data expires from the cache. The cache timeout values are determined by the server that provided the original information.

• Authoritative servers come in several varieties:

  • Master name servers hold the official copy of the DNS data records for a zone. This data is stored in configuration files. Previously, master name servers were called primary name servers, and you may also see the term primary master name server from time to time.

  • Slave name servers , which are also authoritative with respect to the data for their zone. These servers obtain the DNS data records from the zone's master servers. Slave name servers were formerly called secondary name servers.

  • Stub name servers function like slave name servers, but limit their data to the records corresponding systems that are to name servers.^[4] In other words, ordinary host records are excluded. These name servers are used to make it easy to update the pointers in a parent zone when the name servers in one of its subdomains change.

    ^[4] Specifically, they hold only the SOA record, the NS records, and the A records corresponding to the hosts listed in the NS records.

  • Distribution name servers are name servers (usually slave or stub) whose existence is not publicized beyond the local domain. For this reason, they are sometimes called stealth name servers. These servers are not really invisible, however. Anyone who knows their IP address can send queries to them.

  Stealth servers can also be created inadvertently when a subdomain's parent name server is not configured correctly. If the parent name server has the wrong server listed as the subdomain's name server, then the real name server for the subdomain won't be able to be found by anyone (since the parent zone's name server will give out the wrong address).

• Servers that hold no official DNS records for any zone are known as caching-only name servers, referring to the fact that they retain all information that they learn within their cache (at least for a time).

• Forwarders are name servers that have been designated as the target for queries outside the local domain (i.e., off site queries). When a name server is configured to use a forwarder, it always sends queries for hosts it doesn't recognize to the forwarder. If the forwarder cannot provide the answer, the name server will then attempt to determine the answer itself by contacting other name servers that it knows about.

  If a name server is configured to rely completely on designated forwarders, it is known as a forward-only name server . In this case, if the forwarder does not return the answer, the query will simply fail.

  The idea behind forwarders is two-fold: to channel most queries into a few designated servers and thereby reduce the load on the other DNS servers. Typically, the requests that get forwarded are addresses beyond the local domain, so local name resolution performance is never impacted by remote operations.

  The second advantage of forwarders is that over time they build up a cache with a large amount of data from the remote queries. By having forwarders perform all of these queries, all this data is in one place, and having all remote queries check this server first allows them to take maximum advantage of the results of previous queries (which increases the chances that a desired address will already be known). Contrast this to the situation in which each DNS server performs every query it receives; in this case, the results of previous queries for remote sites will be scattered across the entire local network, and the chances that queries will be unnecessarily repeated are much greater.

We will consider each of the various types of name servers in detail later in this section.

8.1.3 About BIND

The first version of what was to becomeBIND was written in 1984, and many versions have been released in the years since then. Currently, BIND maintenance and development is handled by theInternet Software Consortium, and you can obtain the current source code from them (http://www.isc.org/products/BIND/). As of this writing, the latest version is BIND 9.2.1 (released in May, 2002).

Unfortunately, at the moment, there are three majorBIND versions in actual use: BIND 4, BIND 8, and BIND 9 (which, despite the numbering, are consecutive major releases). Vendors are very slow to upgrade their supplied versions of BIND, and BIND security patches are released much more frequently than operating system updates. Table 8-2 lists the versions of BIND shipped with our reference operating systems. Note that in some cases more recent versions are available for download from the vendor web site.

^[1] Releases with significant known security holes that should be upgraded.

You can determine the BIND version running on a system by checking the system messages file produced by syslog (for the daemon facility) and also with the dig utility (discussed later in this section). If no name server has been configured, you can still find out what version your system includes by starting named manually; it generally starts, reports its version and other information, and then exits when it finds no valid configuration files.

In many cases, the version of BIND shipped by a vendor was the latest available at the time the operating system was released. Security problems with that version were discovered after the release data. As the table indicates, several operating system versions of BIND should be updated from the delivered version (updates are sometimes available at the vendor website).

In the case of AIX and HP-UX 11, the release is so old that I recommend replacing it altogether, with BIND 9 if possible.^[5]

^[5] Some HP-UX versions are incompatible with vanilla BIND 9 and must use BIND 8; see the ISC web site for details. However, you can download HP's port of BIND 9 from http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=BIND9.2.

There are significant differences among BIND versions. Table 8-3 summarizes them; most of the features themselves are discussed in the course of this section (although DNS performance is covered in Section 15.7).

^[6] Some features marked "no" were present in experimental form.

^[7] Added in BIND 8.2.

We will consider only BIND 8 and 9 in the remainder of our discussion, and the appellation "BIND 8" will refer to BIND 8.2.0 and later versions. BIND 8-specific items will be marked with a [8] ; BIND 9 with a [9].

8.1.4 Configuring named

The named server uses several configuration files. We'll begin by looking at the full list briefly and then go on to consider example configurations for several real-world scenarios. For more information about DNS and BIND, including full details about the various configuration files, consult Paul Albitz and Cricket Liu's excellent book, DNS and BIND (O'Reilly & Associates).

NOTE

DNS configuration files are prime examples of configuration files that can benefit from a revision control system. These files are very important and also have a somewhat obscure syntax. Arevision control system like CVS or RCS not only automatically tracks modifications to these files but also makes it easy to revert to a working version should one of the configuration files become messed up by typos or other errors.

Table 8-4 lists the locations of BIND components on the various operating systems.

^[8] AIX and HP-UX are excluded from this table as they provide only BIND 4. In general, the current version of BIND 9 from the ISC is recommended for these systems

8.1.4.1 The master configuration file: named.conf

The file /etc/named.conf is the main configuration file for named.^[9] It specifies the type of name server that will be run and all of its operating characteristics. Entries in this file have the following general syntax:

^[9] Under BIND 4, this file is /etc/named.boot and it is usually referred to as the boot file. The file also has a very different syntax. Note in particular that semicolons no longer mark comments in the new version but instead serve an essential syntactic role within entries.

keyword [argument] { /* This is a comment */ item; // comment item; # another comment ... };

Note that the keyword section and each item within it must be terminated by a semicolon. As the example illustrates, there are three different valid comment styles. The first, C-style format (/* comment */) can span multiple lines. In addition, statements can continue onto multiple lines without any special demarcation because they are always terminated by a semicolon.

Here is a simple version of the named.conf file which illustrates its basic features:

options { Set global options. directory "/var/named"; Directory for other configuration files. pid-file "/var/run/named"; Hold the PID of the named process. }; zone "." { Defines zone for the root servers cache. type hint; Zone type. file "named.cache"; File that contains the data records. }; zone "0.0.127.in-addr.arpa" { Reverse lookup zone for loopback address. type master; This is the master server for this zone. file "localhost.rev"; File that contains the data record. notify no; Don't notify slave servers of updates. };

There are three statements within this file. The first one, options, sets global options for this server. In this case, we specify the directory where the remaining configuration files are located and a pathname for the file holding the PID of the named process.

The remaining two statements define zones and their characteristics. The zone name follows the keyword, and the type option in each statement indicates the sort of zone it is. In this example, the first zone statement corresponds to the root domain, and its type is the special type hint. Such zone entries are used to indicate the location of the root hints file, which contains the addresses of the root zone name servers (discussed in the next subsection). Here, the file is specified as /var/named/named.cache.

The second zone statement defines a zone named 0.0.127.in-addr.arpa, for which this host is the master name server. This zone is a reverse lookup zone. It is used to map an IP address to a hostname. In this case, its data file will map 127.0.0.1 to localhost. The data records for this zone are stored in the file /var/named/localhost.rev. Zone files are discussed in detail later in this section.

Entries like these two will be present in every named.conf file. In fact, the version shown is sufficient for configuring a caching-only name server.

Here are simple zone statements that define a master name server:

zone "ahania.com" { type master; file "ahania.com.db"; Zone file name. }; zone "10.168.192.in-addr.arpa" { type master; file "192.168.10.rev"; Reverse zone file name. };

These two statements are quite similar to the ones we've seen already. They designate this server as a master name server for the ahania.com and 10.168.192.in-addr.arpa zones, the forward and reverse zones for the same set of hosts. The file option in each statement specifies the location of the zone file holding the DNS data records (relative to the default directory). Note that the full named.conf file will also contain an options statement and zone statements for the root hints file and the loopback reverse lookup zone like those we examined previously.

A slave server is equally easy to configure in its most basic form. It includes a zone statement like these in addition to the options statement and root hints file and loopback reverse lookup zone definitions:

zone "ahania.com" { type slave; masters { 192.168.10.1; }; # maximum = 10 masters file "back/ahania.com.bak"; # make backup file easy to find }; zone "10.168.192.in-addr.arpa" { type slave; masters { 192.168.10.1; }; file "back/192.168.10.bak"; };

In these zone statements, the name server type is now slave. The masters statement takes a list of master name server IP addresses from which this slave should obtain the zone data. Multiple servers are contacted in the order in which they are listed, until an answer is received.

If a file option is included, that file is used as a local backup file for the zone data. It is updated every time the slave name server gets new data from a master name server and is loaded when the server starts up. When this happens, the slave name server simply checks to see whether the master name server has more recent data, downloading it only if necessary and thereby providing faster server startup.

A given name server can be a master server for more than one zone and can also be a master server for some zones and a slave server for others.

NOTE

Store up-to-date copies of the zone files on slave servers in a separate directory. That way, it will be easy to promote a slave name server to a master name server in a hurry.

Table 8-5 lists the most important statements and options that can appear in the named configuration file.

We will see examples of most of these statements when we consider the various BIND features. Before we do that, however, we will complete the BIND big picture by looking at the other configuration files.

8.1.4.2 The root hints file

In addition to any data records for the zones they serve, all name servers also need to have information about the DNS root domain to resolve hostnames beyond the local domain (because a query for a remote site may need to be forwarded there). As we saw, the named.conf file contains a zone definition for the root zone having zone type hints. The file specified in this statement is known as the root hints file. It contains the IP addresses of the name servers for the root domain. You can select any name you like for this file. Commonly used names are named.root, db.cache and root.hint.

The root hints file has the same form and contents on every DNS name server (at least it should). You can obtain the standard file by retrieving the file /domain/named.root from ftp.rs.internic.net using anonymous FTP.

Here is part of the current version of the file, with additional annotations:

; Name server definitions ;Zone TTL Class Type Host . 3600000 IN NS A.ROOT-SERVERS.NET. . 3600000 IN NS B.ROOT-SERVERS.NET. ; ; Map the hostnames to IP addresses ;Host TTL Class Type IP Address A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 B.ROOT-SERVERS.NET. 3600000 IN A 128.9.0.107

This excerpt defines two name servers for the root zone in its first two entries on lines 3 and 4, after the comments (which are indicated by semicolons). The fields in these two entries hold the zone name, the cache lifetime (time-to-live, or TTL) for this record on remote servers (in seconds), the class (virtually always set to IN for Internet), the record type (here, NS for name server), and the name server hostname.

The final two lines of the file specify the IP addresses corresponding to these name servers. These fields in these entries hold the hostname, the cache TTL, the class, the record type (A for address), and finally the IP address assigned to this host.

The format of the records in this file are the same as those for any DNS zone file. We will discuss their format in detail in the next section. The records in the root hints file are loaded into the name server when it starts, and the file is not consulted thereafter. You will need to obtain the current version of this file from time to time (a few times a year).

8.1.4.3 Zone files

Zone files hold the actual DNS data records for master name servers. This data is loaded when the server starts up. Entries within a zone file are known as DNS resource records , and they have the following general syntax:

entity-name [ttl] IN record-type data

entity-name is the item that is being defined or specified, ttl is an optionaltime-to-live value (cache lifetime in seconds), IN is the class (Internet), record-type is a code string indicating the kind of record this is, and data is the value, mapping, or other data being associated with this entity.

Table 8-6 lists the most important types of DNS resource records, along with their basic zone file syntax. We've omitted the optional TTL field in the table.

There are also a fewdirectives which may be used in a zone file:

$TTL time Default TTL for cached address mappings. $ORIGIN domain Specify/change default domain context. $GENERATE range record-template Automatically generate resource records. $INCLUDE path Insert external file's contents.

An initial $TTL directive is required byBIND 9. Its argument is a time period expressed either as a plain number (interpreted as seconds) or as a number followed by a units code letter: s (seconds), m (minutes), h (hours), d (days), or w (weeks). These same code letters can be used in the TTL field of other resource records and within the appropriate start of authority record fields.

We'll now examine excerpts from a forward zone file, which illustrate many of these resource types. Here is the beginning of the file:

$TTL 24h Lifetime for cached mappings. @ SOA IN ns.ahania.com. chavez.dalton.ahania.com. ( 200204010 ; serial Indicates the zone file version. 5h ; refresh (5 hrs) Slaves check for updates this often. 1200 ; retry (20 mins) Retry a failed update after this long. 4w ; expire (28 days) Discard zone data if master down this long. 3600 ; minimum (1 hour) Cache lifetime for negative answers. )

The zone file begins with a $TTL directive setting the default timeout period for cached mappings to two hours.

Next comes the SOA record. This one continues over several lines, indicated by the parentheses. The first line specifies the zone (the @ symbol is shorthand for the zone specified in the corresponding zone statement in named.conf), record type and class (SOA and IN), the zone's master name server (usually the current host), and the administrative contact's email address. The zone statement referencing this file defines the ahania.com zone.

Notice that the latter two fields use a variant of the normal syntax. First, both end with a dot. In DNS resource records, absolute host and domain names end with a dot (which represents the root domain). Names not ending with a dot are assumed to be relative to the current zone. Leaving off a dot when it is needed is the most common error made by beginners, and doing so will cause queries for these names to fail. Secondly, the @ sign usually present in an email address is replaced by a period.

The remaining fields in the SOA record specify various timeout periods. Most of them apply to slave servers for this zone. Their meanings are described in the annotations. However, a few additional points are in order:

• The serial number field should be incremented each time the zone file is modified. It is used by slave servers to determine whether their data is current. Serial numbers need not be consecutive but must always increase. (This is an unsigned 32-bit value.)

  A common practice is to use serial numbers of the form yyyymmddn (e.g., 200210243). This allows for up to 10 changes per day, and you can use two n digits if you need more than that (and you have my sympathy).

• The final field has different meanings in BIND 8 and BIND 9. In the former, it sets the default record TTL value for both positive and negative query responses. In version 8.2 and higher, it sets only the latter. The default TTL value is set with $TTL in those versions.

• Timeout period recommendations:

  • Refresh periods are generally a few hours, but a shorter or longer period may be appropriate, depending on the volatility of your site (I decrease this value to two hours if DHCP is also used).

  • The data expiration period is typically set to one or two weeks.

  • One to three hours is a good range for thenegative query cache lifetime (the latter is the maximum). Positive cache lifetimes tend to be longer; I use one day on my systems.

  • The best retry interval is highly dependent on what tends to cause server outages and how long they tend to last. I chose the value of 20 minutes because that's a good value when a system has crashed due to a power outage caused by an electrical storm, my prime nemesis when it comes to system uptime.

Here is the next section of the file:

; Define name servers for this zone. ahania.com. IN NS ns.ahania.com. ahania.com. IN NS lyta.ahania.com. ; Specify some name-to-IP address mappings. ns.ahania.com. IN A 192.168.10.1 lyta.ahania.com. IN A 192.168.10.10 talia IN A 192.168.10.12

The first two records define authoritative name servers for the specified zone, ahania.com. The records do not distinguish between master and slave servers; that is done in named.conf. Generally, all authoritative name servers for the current zone and all of its subdomains (child zones) are included in the zone file. We'll see examples of the latter further on in this section.

The second section in the preceding zone file excerpt defines three hostname-to-IP address mappings for hosts in this zone. The third entry, for host talia, illustrates the use of a relative hostname (without a final dot).

The following records illustrate some zone file shortcut features, as well as several other record types:

; Some records for host susan. susan.ahania.com. IN A 192.168.10.11 IN MX 10 susan.ahania.com. www.ahania.com IN CNAME susan.ahania.com. ; Advertise the FTP service. _ftp._tcp.ahania.com. IN SRV 10 0 21 lyta.ahania.com. _finger._tcp.ahania.com. IN SRV 0 0 79 . ; none available

The first three records all apply to host susan. Because the first field in each of the first two lines is the same, it can be omitted from the second one. The first record is an A record that specifies susan's IP address.

The second record for host susan is an MX ("mail exchanger") record. This type of record specifies the host to which mail addressed to anyone@susan.ahania.com should be delivered. In this case, it is host susan itself. MX records are discussed in detail in Section 9.1.

The third line holds a CNAME record that defines an alternate name for host susan (more precisely, it maps an alias to the host's canonical name). It defines www.ahania.com as an alias for susan.ahania.com, and queries for the alias will return the IP address that is associated with susan.

The final two records in the preceding example are SRV ("server selection") records. This record type is used to advertise the availability of a specific network service within a specified domain.^[10] These records are just beginning to be used in the Unix world, but Windows 2000 and its successors make extensive use of them. The first field in the record holds the encoded service specification (_service._tcp-or-udp.domain), and the final four fields hold the server's priority (used to select among multiple available servers), weighting value (used to perform primitive load balancing among servers of equal priority), the port number, and the host offering the service. SRV records are described in detail in DNS and BIND.

^[10] Previously, advertising such services relied on defining generic hostnames like ftp.ahania.com.

The first SRV record indicates that lyta offers the FTP service for the ahania.com domain, using the standard FTP port (21/tcp). The second SRV record uses a dot as the server host name, and it will result in negative responses to general DNS queries attempting to locate a finger service in this domain. Service names are those defined in /etc/services, and the protocol is always _tcp or _udp.

NOTE

Beginning DNS administrators often make these two mistakes: forgetting to update the serial number after editing a zone file and forgetting to include final periods when specifying absolute host names. The first mistake results in secondary servers not being updated when they should be, and the second mistake results in the definition of names like something.ahania.com.ahania.com.

8.1.4.3.1 Reverse zone files and PTR records

Reverse zone files are very similar to the zone files we've just looked at. For example, here is a file that can be used for the 0.0.127.in-addr.arpa zone hosted by every name server:

$TTL 4w @ IN SOA ns.ahania.com. chavez.dalton.ahania.com. ( ...Usual items. ) 1 IN PTR localhost.

Following the SOA record, this file's sole record maps the host address 1 to the hostname localhost. The host address is added to the network address specified in the zone name, so this PTR ("pointer") record maps 127.0.0.1 to localhost.

Here are the PTR records corresponding to the hosts in the preceding forward zone file for ahania.com:

1 IN PTR ns.ahania.com. 10 IN PTR lyta.ahania.com. 11 IN PTR susan.ahania.com. 12 IN PTR talia.ahania.com.

These records would be found in the zone file for the 10.168.192.in-addr.arpa reverse lookup zone. All of the hostnames are specified in absolute form since the default zone context is the reverse lookup zone (and not the corresponding forward zone).

You can include multiple subnets in the same reverse zone file if appropriate. For example, these records come from the file 168.192.in-addr.arpa:

1.10 IN PTR ns.ahania.com. 10.10 IN PTR lyta.ahania.com. 11.10 IN PTR susan.ahania.com. 12.10 IN PTR talia.ahania.com. 1.20 IN PTR moonlight.ahania.com. 2.20 IN PTR starlight.ahania.com.

This file contains PTR records for hosts on the 192.168.10 and 192.168.20 subnets.

8.1.4.3.2 IPv6 zone file resource records

The normal A records do not support IPv6 addresses, so an additional resource record type has been defined: AAAA.^[11] Here is an example:

^[11] Another scheme, using A6 and DNAME resource record types, is also implemented in BIND 9. For a long time, the two schemes competed, and A6 seem likely to win. However, in mid-2002, the proposed standard using them was reclassified to experimental status. As of this writing, the AAAA-based scheme remains a proposed standard. See http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-addresses-02.txt for details.

six.ahania.com. IN AAAA 4321:0:1:2:3:4:567:89ab

An additional reverse mapping space has been defined for these addresses: ip6.int, and it is specified in PTR records for such hosts. Here is the pointer record for the preceding example (wrapped):

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.int. IN PTR six. ahania.com.

Note that all zeros must be included in the reverse address.

8.1.4.4 Common mistakes to avoid

Here are some mistakes that are commonly made by new DNS administrators that you can avoid:

• Life, and administering DNS, is much easier if you limit hostnames to alphanumeric characters.

• Systems listed in NS records must always use the hosts' actual, fully qualified domain names. Never use a CNAME alias in this context.

• The same point applies to MX records: specify only real, fully qualified domain names as the target hosts.

• Email delivery problems are often caused by improper or missing PTR records for name servers or MX hosts. Be sure that these records exist and that they are correct.

• Do not use wildcards in MX records.

8.1.4.5 Using subdomains

Defining subdomains is only a bit more complicated than the configuration for single-level domains. Here are the steps for doing so:

• Decide on the subdomain strategy and divisions and assign responsibility to the appropriate administrator(s).

• Create the named.conf file and the forward and reverse zone files for the master name servers for the new subdomain.

• Delegate the authority for the new subdomain via NS statements within the parent zone.

For example, these resource records define the asia.ahania.com subdomain when they appear in the zone file for ahania.com:

; asia subdomain asia.ahania.com. IN NS ns.asia.ahania.com. IN NS test.asia.ahania.com. IN NS atlas.zoas.org. ; glue records ns.asia.ahania.com. IN A 192.168.24.10 test.asia.ahania.com. IN A 192.168.24.24

The first three records define name servers for the asia.ahania.com subdomain, thereby delegating authority for these zones to them. The other two records in the file are normal A records defining the IP addresses of these name servers. These are referred to as glue records since they provide the data necessary for the locating the subdomain's name server. Without them, the parent zone's name server would have, for example, no way to resolve the hostname ns.asia.ahania.com (it's a chicken and egg problem) and so would not be able to refer or follow queries into the subdomain. Nevertheless, the records are really foreign to the parent zone file. Note that no glue record is needed for the third name server, atlas.zoas.org, since its IP address can be determined with a normal DNS query.

Delegating the corresponding reverse lookup zone is simple if the new zone is a distinct subnet and the parent zone is situated one level above it in the hierarchy. In this case, the new zone corresponds to the 192.168.24 subnet. If the ahania.com name servers also handle the 168.192.in-addr.arpa zone, records like these delegate the 24.168.192.in-addr.arpa zone to the same name servers as for asia.ahania.com:

; 24.168.192.in-addr.arpa subdomain 24 IN NS ns.asia.ahania.com. 24 IN NS test.asia.ahania.com.

Note that glue records are not needed here, since the name server IP addresses can be determined with an ordinary DNS query.

8.1.4.5.1 Reverse zone files with arbitrary subnetting

Standard DNS reverse zone files and PTR records assume that the network-host address separation falls on a byte boundary. If this is not the case, there is a technique to work around this limitation known as the "CNAME hack" (although it has since become official in RFC 2317). It involves creating a series of CNAME records for each numeric host ID along with NS records for the name servers that hold the actual PTR records for each subnet.

For example, suppose our network is 192.168.88.0/27. We have 8 subnets of 30 hosts each. If we want to delegate the PTR records for each subnet to their own name server, we use resource records like these:

Zone file for the 192.168.88 domain $ORIGIN 88.168.192.in-addr.arpa. Set default domain: append to relative names. 1 IN CNAME 1.sub0 1.sub0 is an alias for 1.88.168.192.in-addr.arpa 2 IN CNAME 2.sub0 ... 30 IN CNAME 30.sub0 33 IN CNAME 33.sub1 ... sub0 IN NS ns.zoas.org. Name servers for the first two subnets. sub1 IN NS ns2.essadm.com. Reverse zone file for sub0.88.168.192.in-addr.arpa (on ns.zoas.org) 1 IN PTR spring.zoas.org. 2 IN PTR charles.zoas.org. ... 30 IN PTR helen.zoas.org. Reverse zone file for sub1.88.168.192.in-addr.arpa (on ns2.essadm.com) 33 IN PTR monica.essadm.com. ...

What happens when the domain's name server receives a translation request for 192.168.88.2? This is a request for the PTR record corresponding to 2.88.168.192.in-addr.arpa. The name server recognizes that name and returns the target of the CNAME record, here 2.sub0.88.168.192.in-addr.arpa, as well as the address of the name server for the corresponding reverse zone, ns.zoas.org (we've listed only one, but real files would have at least two per subnet). In this way, a query for an IP address translation is redirected by the CNAME records to the proper name server for the corresponding subnet. When that server is contacted, it can reply with the actual hostname from the PTR record for 192.168.88.2: spring.zoas.org.

The effect of this strategy is to insert an additional pseudo-component into the zone structure that can vary by subnet. Here, we've used sub0, sub1, and so on. In this case, each subnet is actually a different site (as might be common at an ISP).

In actual practice, the subnet component is named after the numeric range of the host part of IP addresses within the subnet. In other words, sub0 would be 0-31, sub1 would be 32-63, and so on. In the same way, the resource records applying to host 2 would be:

$ORIGIN 88.168.192.in-addr.arpa. 2 IN CNAME 2.0-31 2.0-31.88.168.192.in-addr.arpa. IN NS ns.zoas.org.

As illustrated in the NS record, absolute names are often used in the resource records as well. These sort of names are more descriptive for experienced administrators, but I think the technique is harder to grasp when first presented with names that are this hard to parse.

This technique can produce a very long and tedious zone file. The $GENERATE directive can be used to create the required records quickly, in a single operation. For example, these directives create all of the CNAME records required for the first two subnets in the previous example:

$ORIGIN 88.168.192.in-addr.arpa. $GENERATE 1-30 $ IN CNAME $.0-31 $GENERATE 33-62 $ IN CNAME $.33-63 0-31 IN NS ns.zoas.org. 32-63 IN NS ns2.essadm.com.

The dollar sign within the $GENERATE directive's record template is replaced by each number in the specified range in turn, causing each such directive to create 32 CNAME records.

See DNS and BIND for full details on this topic.

8.1.4.6 Forwarders

So far, we have ignored the nitty gritty details of how DNS queries are performed, but we can do so no longer. When a hostname needs to be resolved to an IP address, a local name server is consulted first. If the local name server does not know its address or the address of a name server in the corresponding domain, the name server consults one of the servers in the root zone. The name server asks the root name server for the address of a name server in the appropriate TLD and then gradually works its way down the domain hierarchy until it arrives at the target domain and obtains the desired IP address.

For example, when trying to resolve ns.asia.ahania.com from, say, four.zoas.org, the latter host first contacts a local name server. That server may not recognize the target host or even any part of the domain list within the name, so it contacts one of the root name servers. In this case, the local name server may not know asia.ahania.com or ahania.com or even .com, so it has to ask a root name server for help. The root name server provides the local name server with a referral to a name server for .com. Things continue in this way, moving down to ahania.com and then finally to asia.ahania.com, where the desired address is obtained.

When you consider a large, very active site with many connections to foreign sites, it becomes clear that having every name server resolve such hostnames is not the most efficient strategy. For example, clients in two separate subdomains attempting to connect to the same foreign site would both cause their name server to do all the work of resolving the hostname.

Forwarding provides a ways of channeling external name resolution queries through a few designated servers. Doing so has several benefits:

• Identical queries are not repeated during the record's cache lifetime.

• Information gained from one query can be used in others. For example, finding a name server for .com needs to be done only once.

• All of the external hostname information can be collected into one or a few locations, making it easily accessible to everyone at the site.

• The load placed on local name servers by queries for remote sites is minimized.

Forwarders are designated by having other name servers point to them rather than via any configuration options on the server itself. For example, the following options configure the server to use designated forwarders for all zones:

options forwarders { 192.168.10.50; 192.168.24.6; }; forward first; };

The forwarders option specifies a list of name servers to consult for all external queries that cannot be resolved from its cached translation data. In this example, two name servers are listed. The forward option takes a keyword as its argument. The keyword first says that forwarders should be consulted for appropriate external queries (in the order they are listed), but if none of them succeed in resolving the hostname, then the server will attempt to resolve it itself (this is the default). The other possible keyword, only, suppresses the server's own name resolution attempt should all of the forwarders fail.

These options may also be specified within a zone statement to limit forwarding to that zone, to define a different forwarders list for that zone, or to specify different forwarding behavior in that zone. In this case, the zone type is usually set to forward:

zone "forward.ahania.com" { type forward; forward only; forwarders { 192.168.10.50; 192.168.24.6; }; };

Not everyone agrees that using forwarders is always the way to go. One of the book's technical reviewers explains the alternate viewpoint:

While forwarders do have their place, I personally feel it is much better to limit the number of name servers per physical site. We have two caching-only name servers that service about 90% of our 45K host network. We get really good cache performance because everyone uses them. Giving each network their own name server would just be a waste of resources.

The one good reason to have forwarders or more caching-only servers is if you have two different physical sites, each with their own ISP link. You don't want to make the usability of one site's link dependent on the other.

8.1.4.7 Slave name server notifications

As I've already mentioned, slave servers check whether their data needs to be updated whenever they start up. In addition, by default, masters also notify all slave servers they know about whenever the zone data changes, either because the zone file has been edited or due to dynamic updates to its data from DHCP (discussed below). When they receive such DNS notification messages, slave servers compare the master server's serial number with the version they have, retrieving the updated data when appropriate.

Notification is enabled by default, but it can be disabled with the following option to either the options or zone statement:

notify no; The default is yes.

BIND 9 adds a third keyword: explicit. This keyword allows you to limit update notifications to the list of name servers specified in the options statement's allow-notify option. For example:

options { notify explicit; allow-notify { 192.168.10.1; 192.168.20.2; ...; }; };

Finally, you can specify additional slave name servers that should be notified of changes with the also-notify substatement, which can be used with either the options or zone statement. This option is needed when there is a slave name server that needs updates but is not listed in an NS record in the zone file, e.g., a slave name server that is only accessible from within the site but needs to receive updates from a name server providing external name resolution of internal names.

8.1.4.8 Dynamic updates

Using DHCP for client address assignment greatly complicates the original DNS scheme. Traditional servers do not expect hostname mappings to change very often, so the static data files used by traditional DNS are a storage mechanism that works fine. However, when IP addresses are changing on a frequent basis, manual maintenance of DNS records becomes impractical.

BIND can be configured to accept dynamic updates: hostname and IP address pairings from DHCP servers as they are assigned. Such updates can add, remove, and/or modify DNS records. Dynamic updates must be sent to an authoritative name server for the zone. Slave name servers that receive them forward them to the master name server (which has the only modifiable copy of the zone data).

Dynamic updates are enabled on a per-zone basis, via the allow-update option to the zone statement. For example, the following statement enables dynamic updates for the dhcp.ahania.com zone:

zone "dhcp.ahania.com" { type master; file "dhcp.ahania.com.db"; allow-update { 192.168.33.3; 192.168.33.5; }; };

In this case, dynamic updates will be accepted only from the two listed servers.

The allow-update-forwarding option in BIND 9 can be used to specify a list of servers from which a slave name server will forward dynamic updates to the master name server:

zone "dhcp.ahania.com" { type slave; masters { 192.168.33.62; }; file "back/ahania.com.bak"; allow update-forwarding { 192.168.33.32/27; }; };

As you can see, its syntax is very similar to allow-update. In this case, updates from any system on the specified subnet are allowed.

BIND 9 also provides the update-policy option as an alternative to allow-update. It takes a much more complex dynamic access specification as its argument, consisting of one or more access rules have this general form:

grant|deny who-key what where [record-types];

who specifies the source of the update via the key name for that entity (keys are discussed in a later subsection). This forces all dynamic updates to be cryptographically signed.

What is a keyword indicating the subset of the next argument to which updates may be made, where is the domain or subdomain to be updated, and record-type is a list of resource record keyword for the kinds of records to which the rule applies.

The possible values of what are:

name

The update must be to the domain in the where field.

subdomain

The update must be to a subdomain of the domain in the where field (within the same zone). In other words, the name to be updated must end in where.

wildcard

The domain to be updated must match the wildcard string in the where field.

self

The update must apply to the entity specified in the who field itself. In this case, where must still be specified, but it is not used.

Here are some examples:

Allow ns.dhcp.ahania.com to modify domain records via signed updates grant ns.dhcp.ahania.com. name ns.dhcp.ahania.com.; Allow subdomain clients to update only their own address records grant *.dhcp.ahania.com. self dhcp.ahania.com. A; Allow only ns.win2k.ahania.com to modify SRV records in its zone grant ns.win2k.ahania.com. subdomain _udp.win2k.ahania.com. SRV; grant ns.win2k.ahania.com. subdomain _tcp.win2k.ahania.com. SRV; deny *.win2k.ahania.com. wildcard *.win2k.ahania.com. SRV;

The rule list is specified as the argument to update-policy:

zone "dhcp.ahania.com" { type master; file "dhcp.ahania.com.db"; update-policy { grant *.dhcp.ahania.com. self dhcp.ahania.com. A; }; };

Note that ordering is important within rule lists, because the first matching rule is used, even when a later rule would be a closer (more explicit) match. As usual, more specific rules generally precede ones that apply more widely.

See DNS and BIND for more sophisticated examples of this option.

8.1.4.9 Incremental zone transfers

When a master name server sends the zone data to a slave name server, the process is known as a zone transfer. By default, the entire zone contents are transmitted. However, in some circumstances, the master name server can send only those records that have changed since the last update, via an incremental zone transfer. These two types are also known as AXFR and IXFR, respectively (after the query type that is used).

Incremental zone transfers are enabled in the named.conf file, via the options and/or server statements. The latter statement is used to specify how the local server should communicate with specific other name servers. Here are example statements for enabling incremental zone transfers:

Under BIND 8, the maintain-ixfr-base option tells the name server to maintain a transaction log from which incremental transfer data can be drawn. The server statement means that IXFR will be used when communicating with the specific server system.

Under BIND 9, incremental zone transfers are enabled by default for all zones that are configured for dynamic updates (and the transaction-based data is always maintained). The two options within the server statement indicate whether the local server will provide or accept incremental zone transfers to the specific system, as appropriate. The provide-ixfr option applies only when communicating with slave name servers, and request-ixfr applies only when communicating with a master name server.

In practice, these options are often used to disable IXFR (with an argument of no), since the default is to use incremental zone transfers. They are also used to identify servers that do and don't support IXFR within a network with name servers using different DNS versions and hence with differing capabilities.

8.1.4.10 Access control

As we've seen, many BIND statements take a list of addresses as their argument. So far, we have provided only literal lists of IP addresses. There is another possibility, however. The acl statement^[12] is used to define an address match list . Here is an example:

^[12] Despite its name, this statement does not define a true access control list, but merely a list of IP addresses and patterns to match that can be used in other security-related statements.

# Define a list of our name servers. acl "servers" { 10.1.10.50; 10.1.20.1; 10.1.30.200; }; # Define another list. acl "sample" { List name is "sample." 10.1.10.1; IP address. ! 10.1.20.200; ! means NOT: exclude this IP address. 10.1.20/24; Specifies a subnet. servers; Include another address match list. };

As usual, ordering with an address match list is important, because the first match is used (this matters when you are combining positive and negative matches). Note that the exclamation point negation character applies only to the item that it precedes (i.e., it does not "stick"). Address match lists must be defined before they are used. In general, address match lists may be used anywhere that a list of hosts is expected.

BIND provides four predefined address match lists: none (matches nothing), all (matches any IP address), localhost (matches any IP address assigned to the local system), and localnets (matches all subnets to which the local system has an interface attached).

Here are some example uses of address match lists:

acl "extern" { 192.168.1.100; 192.168.20.200; }; acl "hidden" { 192.168.50.25; 192.168.50.26; }; acl "testers" { 10.20.30.100; 10.20.30.101; }; options { directory "/var/named"; forwarders { extern; }; also-notify { hidden; 192.168.51.77; }; allow-query { localnets; }; ... }; zone "experiment.zoas.org." { type master; file "exper.zoas.org"; allow-query { testers; }; };

Various items in the options statement use address match lists to specify the list of forwarders, most of the list of additional servers that should be sent zone file data modification notifications, and the list of hosts that are allowed to query this name server. In addition, an address match list is used to limit the hosts allowed to query this name server for the zone experiment.zoas.org to the two specified in the testers list.

The allow-query option is one of several that enable you to restrict various types of access to the data on a name server. The complete list is given in Table 8-7. These options may appear in either the options statement or a zone statement.

While address match lists provide ways to limit access to data records, they are not a foolproof mechanism. For example, the source of queries or requests could be impersonated by a bad guy. Cryptographic techniques for securing and authenticating communications are needed for a truly secure DNS environment. The next section will consider the various available options.

8.1.4.11 Securing DNS communications

Both BIND 8 and 9 can be configured to use transaction signatures for communicating between pairs of name servers. This mechanism, known asTSIG, uses a symmetric encryption scheme (the same key is used to encrypt and decrypt a message) for signing server-to-server queries and responses. In this way, messages purportedly from a specific server can be verified as originating from that server. Note that this scheme simply signs the messages; the transmitted data is not encrypted (because it is not secret). See Section 7.4 for a detailed discussion of signing and encryption.

You set up name servers to use TSIG via these steps:

• Create a key using a utility provided with BIND on one system.

• Send the key to the other system in some secure way (e.g., via a telephone call, using an sshssh-based copy operation, etc.).

• Define the key with key statements and specify it for use in server and zone statements within the two named.conf files. Note that the key must be given the same name on both systems (as well as having the same value).

• Restart both name servers. Subsequent communications between them will then be signed.

Here are the commands for creating a key:

# dnskeygen -H 128 -h -n apricot-mango.ahania.com. BIND 8 # dnssec-keygen -a HMAC-MD5 -b 128 -n HOST \ BIND 9 apricot-mango.ahania.com. Kapricot-mango.ahania.com.+157+52961

Each command creates the specified key as 128 bits long, type HOST, using the HMAC-MD5 algorithm. Conventionally, key names resemble domain names, with the pair of systems to which they apply specified as the first component (here, apricot and mango).

The commands create two files beginning with the name displayed in the output, one with the extension .key and the other with the extension .private. The filename is of the form Kkey-name+algorithm+fingerprint, where algorithm is the algorithm number, and fingerprint is a hash value computed from the key used to identify it (functioning like an instance number).

The actual key is included in both files. For example:

# cat Kapricot-mango.ahania.com.+157+52961.private Private-key-format: v1.2 Algorithm: 157 (HMAC) Key: QiL+oT+iV9EHxhbYRcdG8g== This is the string you want.

The key must now be transmitted to the other system in some secure way (i.e., other than via a clear network transmission).

Once the files are present on both systems, the servers can be configured to use TSIG communications. Here are some example statements from named.conf on the slave name server mango that make use of this key:

include "keys.list"; Keys are stored in a separate, non-readable file. zone paranoia.ahania.com. { type slave; masters { 192.168.10.214; ... }; }; server 192.168.10.214 { # apricot keys { "apricot-mango.ahania.com." }; };

The first statement includes the contents of another file within this configuration file, and the second statement defines a zone. The final statement specifies that zone transfer requests to 192.168.10.214 will be signed with the specified key.

The actual key statement is within the included file (which is also protected from non-owner access):

# keys.list key "apricot-mango.ahania.com." { algorithm hmac-md5; secret "encoded=string=goes=here"; };

On the master name server apricot, the key is used in the zone statement to require that zone transfer requests be signed with that key in order to be honored:

include "keys.list"; Same file as on mango. server 192.168.10.100 { # mango keys { apricot-mango.ahania.com.; }; }; zone paranoia.ahania.com. { type master; file "paranoia.ahania.com"; allow-transfer { key apricot-mango.ahania.com.; }; };

The key name construct replaces the address list in the allow-transfer option. Keys may also be specified in the same way within the allow-update and update-policy options in the zone statement.

8.1.4.11.1 BIND 9 security futures

While the TSIG mechanism works well for communication between pairs of hosts, it does not scale well to large sites with many name servers, due both to the significant amount of work required to configure name servers and periodically generate keys (as with any shared secret, keys should be changed regularly) within even a medium-sized site, and the logistical impossibility of setting up TSIG between every pair of name servers worldwide that might ever want to communicate. The first of these issues can be addressed by automating key generation and distribution.

BIND 9 extends the TSIG facility via the use of the TKEY mechanism. In this scheme, known as the Diffie-Hellman algorithm, the two servers automatically exchange data values that each one has computed from a random number and its key. Using the data from the other server and their own key, they then compute the same shared secret key. TKEY's advantage is that the actual key itself does not need to be sent from one server to the other. Although some of the infrastructure for the TKEY mechanism is present in configuration file options, the named server does not yet support TKEY as of this writing (Version 9.2.0 is latest to be released).

BIND 9 also includes the DNS Security Extensions (DNSSEC) facility, a far more elaborate and sophisticated set of mechanisms and procedures for securing DNS communications using public key cryptography. Asymmetric key pairs are used to create the digital signatures, with the private key used to decrypt what the public key has encrypted (or vice versa; see Section 7.4). Once again, the data itself is not encrypted.

DNSSEC uses several new resource record types:

• KEY records are used to store the public key for a zone. The keys for a zone must be signed by its parent zone to create a chain of trust for DNS communications.

• SIG records are used to store the digital signature produced by the zone's private key for each resource record set (the set of all records of a specific type: all A records, all MX records, and so on). This signature is a secure hash performed on the zone data using the private key.

• NXT records are used to specify the next record within the zone when it is placed into its canonical order (a hierarchical and alphabetical ordering scheme defined as part of DNSSEC). These records are returned whenever a negative answer to a query e.g., that host doesn't exist is required, and they too can be signed (while a null response can't).

At this time, DNSSEC is still considered experimental, and there are several outstanding issues that stand between its present form and its production deployment.

• Vital parts of the infrastructure do not exist (e.g., the ability for zones to be signed by the .com domain). DNSSEC can still be used locally, however.

• It takes a significant amount of CPU resources and elapsed time to generate the SIG and NXT records for a zone, and not all current systems running DNS servers would be up to the task. In addition, the time that would be required to sign major TLDs seems to be unrealistic with respect to practical considerations.

• The amount of data within a zone is multiplied by a factor of three or more. This increases DNS network bandwidth requirements significantly.

• Not all functions work when DNSSEC and non-DNSSEC implementations are both used within the same network (e.g., queries from a DNSSEC-aware resolver to a non-DNSSEC forwarder).

In conclusion, while it is probably time to start learning about and experimenting with DNSSEC, it is still fairly far away from production use.

8.1.4.12 BIND 9 views

I've alluded to the practice of keeping internal DNS data private and inaccessible to external queries while still allowing internal users to resolve external name servers as needed. Such a separation is sometimes referred to as split DNS. BIND 9 offers a new feature that makes implementing such a design very easy: views.

Views are a means of varying the properties of a zone depending on who is using it. For example, the zone can appear one way to internal users and another way to external users. Here are some example view statements that illustrate this feature:

acl "internal" { 10.1.1.0/24; }; acl statements must be outside views. acl "external" { any; }; The any keyword matches any address. view "inside" { Zone definition for internal clients. match-clients { "internal"; }; zone "public.zoas.org." { type master; file "public.zoas.org.zone.internal"; }; }; view "outside" { Zone definition for everyone else. match-clients { "external"; }; recursion no; zone "public.zoas.org." { type master; file "public.zoas.org.zone.external"; }; };

First, we define two address match lists, which are then used with the match-clients options inside the two view statements. As usual, the first match-clients option that applies is used, so view ordering is important (if these two views were reversed, everyone would see only view outside).

The same zone, public.zoas.org, is defined in each view, but different zone files are used in each case. In addition, recursive queries are disabled in the outside view; if the name server cannot resolve a name, it does not contact any additional servers in an attempt to do so.

See the excellent article "Supporting Screened Hosts with BIND 9.x Views" by ScottDeJong (Sys Admin magazine 11:5, May 2002) for more complex view scenarios.

8.1.4.13 Securing the named process

Making server-to-server communications and zone data access secure is important, but you also need to ensure that the BIND server itself is not a trouble spot. There are three things you can do to protect it:

• Make sure that named has been patched with all available security fixes. Check your vendor's or the ISC web site regularly to determine if any new fixes have been released, and install them right away. Monitor security news groups and/or mailing lists to ensure that you'll hear about detected problems right away.

• Don't run named as root. Create a special user and group, often called named, to run it. Use the named command's -u username option to start the server running as the specified user. Grant this user access to the various configuration files by changing their ownership (e.g., for key files) or protection.

• Run named in a chrooted environment. The named command's -t directory option can be used to specify the new root directory. Of course, you'll need to set up the required directory structure under the selected root directory and copy all required files there:

  • /etc/named.conf

  • The named executable, along with any required libraries (BIND 8 only). Alternatively, you can link named statically when you build it to avoid any dependencies.

  • /dev/null and possibly /dev/random. Use mknod to create them. Here are example commands from a Linux system:

    # mknod /named-root /dev/null c 1 3 # mknod /named-root /dev/random c 1 8

  • The major and minor device numbers vary among Unix versions; use ls -l to determine the appropriate values to use.

  • Under BIND 8, a version of the password and group files containing just the named user and group. BIND 9 consults these files before chrooting, so copying them is not necessary. Note that the home directory for the named user should be / in both cases, not the chosen root directory location (because the specified home directory is interpreted from the named process's perspective).

• You will also need to modify the default directory location to be / in named.conf's options statement.

8.1.4.14 Configuring logging

The destination for status anderror messages as well as what sorts of messages to save are both highly configurable in BIND. This is done via the logging statement. This statement has two distinct parts: definitions of message channels (output destinations) and associations of message categories with target channels.

Here is a simple logging statement illustrating these features:

logging { channel "xfers" { file "logs/named.xfers"; }; channel "to-syslog" { syslog local1; Syslog facility. severity warning; Minimum syslog severity level. }; channel "to-file" { file "logs/named.log"; }; category xfer-in { "xfers"; }; category xfer-out { "xfers"; }; category security { "to-file"; "to-syslog"; }; };

This statement defines three channels: the syslog local1 facility and two files in the logs subdirectory of the named default directory.

The three category lines specify what messages actually go to each potential destination. The file logs/named.xfers will receive all messages about incoming and outgoing zone transfers, the file logs/named.log will receive all security-related messages (approvals and denials of requests), and the security-related messages of level warning and higher will also be logged to the syslog local1 facility (as specified by the severity option in the corresponding channel definition).

There are a few predefined logging channels:

default_syslog Syslog's daemon facility. default_debug The file named.run in the default directory. default_stderr Send messages to named's standard error. null Discard messages.

The default channels all use syslog severity level information (where applicable).

Table 8-8 lists the most important BIND logging categories. In BIND 9, the default logging behavior sends logging category default to the default_syslog and default_debug channels. BIND 8 also logs a few more messages types to each location as well as panic messages to default_stderr.

Some of the BIND 8-only categories will probably eventually be implemented in a future version of BIND 9. They are ignored (with a warning) in named.conf.

8.1.5 Name Server Maintenance and Troubleshooting

Configuring a DNS name server can be a fair amount of work, but even once that is done, there are still additional tasks required to keep it running:

• Add additional name servers if the load on existing ones becomes too great or the topology of your network changes significantly. How you'll handle expected future growth should be part of your name server deployment plan.

• Check for and apply software patches frequently.

• Update the root hints file a few times per year.

• Update zone files as appropriate. Update the reverse zones at the same time, and don't forget to increment the serial number in each file.

• Review DNS logging information on a regular basis.

• Monitor the reliability and performance of your name servers in the context of overall network activity (see Section 15.7).

8.1.5.1 Controlling the named server process

The named process is typically started at boot time by one of the usual boot scripts (often /etc/init.d/named). On systems with System V-style boot scripts, you can also use the same script to stop or restart the daemon:

# /etc/init.d/named restart

As we've seen, you can specify the location of the file that holds the daemon's PID; this file is typically /var/run/named.pid. You can use this information to signal the named process manually, as in this example:

# kill `cat /var/run/named.pid`

Note that killing the daemon is not recommended in general, and especially not if you are using dynamic updates.

The BIND software distribution also provides a utility to manipulate the name server process. This command is named ndc under BIND 8 and rndc under BIND 9. Both support several subcommands: stop terminates the server process after any pending updates are complete, halt stops the server immediately, reload causes the server to reload its configuration and zone files (or just one zone if its name is specified as the subcommand's argument), and dumpdb and stats write the cache contents and server statistics to a log file (by default, named_dump.db and named.stats, respectively). ndc also supports a restart subcommand (which does the obvious).

Here are some examples:

# rndc reload Reload configuration and zone file. # ndc reload # rndc -s apricot stop Terminate a remote name server process.

ndc also supports remote server management, but it is unsecured: any user who can run ndc on an allowed remote system can perform any operation on the system's DNS servers. For this reason, I don't recommend using this feature. Under BIND 9, you can use the controls statement in named.conf to specify a key with which rndc must sign its messages:

include "rncd.key"; controls { inet * allow { 192.168.10/24; } keys { "rndc-key";}; };

The included file contains a key statement defining the specified key in the same manner as we considered earlier.

The rndc command also requires that the key be defined in its configuration file, /etc/rndc.conf :

options { default-server localhost; Manage this server by default. default-key "rndc-key"; Sign messages with this key by default. }; key "rndc-key" { algorithm hmac-md5; secret "a=whole=lotta=characters"; };

You can use command-line options to override both the default server (-s) and the default key (-y).

8.1.5.2 Using the nslookup and dig utilities

The nslookup command is another utility provided as part of the BIND package. It is used to perform ad hoc DNS queries and is very useful fortroubleshooting purposes.

Here is an example of using nslookup in its default mode:

$ nslookup This command starts an interactive session. > mango Look up this host name (local domain assumed). Server: localhost Address: 127.0.0.1#53 Name: mango.ahania.com Address: 192.168.10.100 > set type=PTR Query PTR records (the default is A). > server 10.18.114.44 Use this server for queries. Default server: freya Address: 10.18.14.44#53 > 192.168.10.214 Server: 10.18.114.44 Address: 10.18.114.44#53 214.10.168.192.in-addr.arpa name = apricot.ahania.com. > exit

These commands illustrate using nslookup for forward and reverse queries, including via a different name server.

Examining the SOA record for a zone can be useful at times. It shows the name servers for the zone and the email address for the zone's administrator:

$ nslookup > set type=SOA > state.ct.us Server: ns1.worldnet.att.net Address: 204.127.129.1 Non-authoritative answer: state.ct.us primary name server = info.das.state.ct.us responsible mail addr = hostmaster.po.state.ct.us serial = 2002041801 refresh = 14400 (4 hours) retry = 600 (10 mins) expire = 604800 (7 days) default TTL = 604800 (7 days) state.ct.us nameserver = info.das.state.ct.us state.ct.us nameserver = dbru.br.ns.els-gms.att.net info.das.state.ct.us internet address = 159.247.0.198 dbru.br.ns.els-gms.att.net internet address = 199.191.128.106

You can also use the serial number data in such records to compare the data versions on master and slave servers when you are trying to troubleshoot zone transfer problems.

Setting the type to NS enables you to determine the authoritative name servers for a zone or website. A type of ANY also returns all records associated with a name.

The newer dig utility performs the same functions as nslookup. It has the following general syntax:

dig [@server] name [type] [options]

For example, this command determines the version of BIND that a server is running:

$ dig @bonita.ahania.com version.bind txt chaos .. . ;; QUESTION SECTION: ;version.bind. CH TXT ;; ANSWER SECTION: version.bind. 0 CH TXT "9.1.3" .. .

The output tells us that this server is running BIND 9.1.3.^[13]

^[13] Or at least that it claims to be. In fact, the system administrator can change this string to any value (although most people don't), so the information provided is not always available or reliable.