Setting Up the Data Files
All the data files used by the DNS daemon in.named are written in standard resource record format. Each line of a file is a record, called a resource record (RR). Each DNS data file must contain certain resource records.
Resource Record Types
The most commonly used types of resource records are listed in Table 5-7. They are usually entered in the order shown in Table 5-7, but that is not a requirement.
Table 5-3 Commonly Used Resource Record Types
Type | Description |
|---|---|
SOA | Start of authority |
NS | Name server |
A | IPv4 Internet address (name to address) |
AAAA | IPv6 Internet address (name to address) |
PTR | Pointer (address to name) |
CNAME | Canonical name (nickname) |
TXT | Text information |
MX | Mail exchanger |
In the sample files included in the following sections, @ indicates the current zone or origin and lines that begin with a semicolon (;) are comments.
Setting Up Subdomains
Setting Up Subdomains--Same Zone
The simplest method is to include the subdomain in the parent domain's zone. In this way, one set of DNS servers and data files applies to all the machines regardless of their domain.
The advantage of the same-zone method is simplicity and ease of administration. The disadvantage is that one set of servers has to serve all machines in all of the zone's domains. If there are too many machines, the servers will be overloaded and network performance can decline.
Data files for multi-domain zones must include records for all machines and servers in each domain covered by the zone.
Setting up a multi-domain zone is the same as setting up a zone with a single domain, except that fully qualified domain names are used in the hosts file to identify machines in remote domains. In other words, in the hosts file, when you identify a machine in the server's local domain, you need to use only the machine's name. But when you identify a machine in some other domain, you must identify the machine with a fully qualified domain name in the format: machine.domain.
Server and machine names in hosts.rev and named.local files also need to be fully qualified with domain names. But that is true regardless of whether or not the zone has more than one domain.
Setting Up Subdomains--Different Zones
The advantage of the different-zone method is that you can assign different sets of servers to serve machines in different domains; in that way, you spread out server load so that no group of servers is overloaded. The disadvantage is that setup maintenance is more complicated.
Setting up subdomains that are in different zones is more complicated than including multiple domains in a single zone, because you have to specify how clients in different zones obtain DNS information from the other zones.
To divide a network into multiple domains, create a domain hierarchy. That is, one domain becomes the top domain. Beneath the top domain, you create one or more subdomains. If you want, you can create subdomains of subdomains. But every subdomain has a set place relative to the top domain in the hierarchy of domains. When read from left to right, domain names identify the domain's place in the hierarchy. For example, the doc.com domain is above the sales.doc.com domain, while the west.sales.doc.com domain is below the sales.doc.com domain.
DNS zones acquire a hierarchy from the domains that they contain. The zone containing a network's top domain is the top zone. A zone that contains one or more subdomains below the top domain is below the top zone in the zone hierarchy. When DNS information is passed from one zone to another, it is passed up and down the zone hierarchy. This means that each zone requires records in its data files that specify how to pass information up to the zone immediately above it, and down to any zones immediately below it.
To correctly transfer DNS information from one zone to another in a multi-zone network:
hosts.rev file. There must be a PTR record in each hosts.rev file pointing to the name of one or more master servers in the zone immediately above it. This type of PTR record is exactly the same as any other PTR record in the file, except that it identifies a server in the zone above.
hosts file NS records. There must be a zone NS record in each hosts file identifying each name server in each zone immediately below. This type of NS record requires the name of the zone below as the first field in the NS record. (The name of the zone is specified in the SOA record of the zone's host file.)
hosts file A records. There must be an A record in each hosts file identifying the IP address of each name server in each zone immediately below. This type of A record has to have the name of the zone below as the first field in the A record. (The name of the zone is specified in the SOA record of the zone's host file.)
The example files in the next chapter illustrate a network with two zones.
The DNS Namespace Hierarchy
The entire collection of DNS administrative domains throughout the world are organized in a hierarchy called the DNS namespace. This section shows how the namespace organization affects both local domains and the Internet.
Like the UNIX™ file system, DNS domains are organized as a set of descending branches similar to the roots of a tree. Each branch is a domain, each subbranch is a subdomain. The terms domain and subdomain are relative. A given domain is a subdomain relative to those domains above it in the hierarchy, and a parent domain to the subdomains below it.
Figure 5-1 Domains and Subdomains
For example, in Figure 5-1, com is a parent domain to the Acme, Ajax, and AAA domains. Or you could just as easily say that those are subdomains relative to the com domain. In its turn, the Ajax domain is a parent to four subdomains (Sales, Manf, QA, and Corp).
A domain contains one parent (or top) domain plus the associated subdomains if any. Domains are named up the tree starting with the lowest (deepest) subdomain and ending with the root domain.
How DNS Affects Mail Delivery
In addition address mapping and maps addresses to host names, as discussed in "Name-to-Address Resolution", DNS also helps mail delivery agents, such as sendmail and POP, deliver mail along the Internet.
To deliver mail across the Internet, DNS uses mail exchange records (MX records). Most organizations do not allow direct delivery of mail that comes across the Internet for hosts within the organization. Instead, they use a central mail host (or a set of mail hosts) to intercept incoming mail messages and route them to their recipients.
The mail exchange record identifies the mail host that services each machine in a domain. Therefore, a mail exchange record lists the DNS domain names of remote organizations and either the IP address or the host name of its corresponding mail host.
DNS Configuration and Data Files
In addition to the in.named daemon, DNS on a name server consists of a boot file called named.conf, a resolver file named resolv.conf, and four types of zone data files.
Names of DNS Data Files
So long as you are internally consistent, you can name the zone data files anything you want. This flexibility can lead to some confusion when working at different sites or referring to different DNS manuals and books.
For example, the file names used in Sun manuals and at most many Solaris sites vary from those used in the book DNS and BIND by Albitz and Liu, O'Reilly & Associates, 1992, and both of those nomenclatures have some differences from that used in the public-domain Name Server Operations Guide for BIND, University of California.
In addition, this manual and other DNS documentation uses generic names that identify a file's main purpose, and specific example names for that file in code record samples. For example, Solaris Naming manuals use the generic name hosts when describing the function and role of that file, and the example names db.doc and db.sales.doc in code samples.
For reference purposes, the following table compares BIND file names from these three sources.
Table 5-4 BIND File Name Examples
Solaris Names | O'Reilly Names or other names | U.C. Berkeley Names | Content and Purpose of File |
|---|---|---|---|
/etc/named.conf | /etc/named.conf | /etc/named.conf | The configuration file specifies the type of server it is running on and the zones that it serves as a 'Master', 'Slave', or 'Stub'. It also defines security, logging, and a finer granularity of options applied to zones. |
/etc/resolv.conf | /etc/resolv.conf | /etc/resolv.conf | This file resides on every DNS client (including DNS servers) and designates the servers that the client queries for DNS information. |
named.ca | db.cache db.root | root.cache | This file establishes the names of root servers and lists their addresses. |
Generic: hosts Examples: db.doc db.sales | Generic: db.domain Examples: db.movie db.fx | Generic: hosts Example: ucbhosts | This file contains all the data about the machines in the local zone that the server serves. |
Generic: hosts.rev Examples: doc.rev | Generic: db.ADDR Examples: db.192.249.249 db.192.249.253 | hosts.rev | This file specifies a zone in the in-addr.arpa. domain, a special domain that allows reverse (address-to-name) mapping. |
named.local | Generic: db.cache Example: db.127.0.0 | named.local | This file specifies the address for the local loopback interface, or localhost |
$INCLUDE files | $INCLUDE files | $INCLUDE files | Any file identified by an $INCLUDE() statement in a data file. |
Caution - The IP addresses and network numbers used in examples and code
samples in this manual are for illustration purposes only. Do not use them as shown because they might have been assigned to an
actual network or host.
The named.conf File
The BIND 8.2.4 configuration file, /etc/named.conf establishes the server as a master, slave, or cache-only name server. It also specifies the zones over which the server has authority and which data files it should read to get its initial data.
The /etc/named.conf file contains statements that implement the following.
Security through an Access Control List (ACL) that defines a collection of IP addresses that an NIS+ host has read/write access
Logging specifications
Selectively applied options for a set of zones, rather than to all zones
The configuration file is read by in.named when the daemon is started by the server's start up script, /etc/init.d/inetsvc. The configuration file directs in.named either to other servers or to local data files for a specified domain.