Chapter 5 DNS Administration (Reference)

This chapter covers the following topics.

• Implementing DNS

• Setting Up the Data Files

• Setting Up Subdomains

• The DNS Namespace Hierarchy

• How DNS Affects Mail Delivery

• DNS Configuration and Data Files

• Data File Resource Record Format

Implementing DNS

A Practical Example

This section shows the files you need to implement DNS for a sample Internet-connected network, based on the examples used in this chapter.

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.

This example assumes the following.

• An environment connected to the Internet

• Two networks, each with its own domain (doc.com and sales.doc.com) and its own DNS zone

• The doc.com domain and zone is the top zone over the sales.doc.com subdomain and zone

• Each network has its own network number

• Each zone has a master and one slave server, and the slave server of sales.doc.com is also the master server of doc.com:

Example Boot Files

The following code examples show boot files for the three servers in the two networks:

Example 5–1 Example Boot File for dnsmastr Server

; named.boot file on the dnsmastr (sirius)
; 
; files required by in.named are located here 
directory /var/named
; here are the names of the master files
cache         .                         named.ca
master       doc.com                   db.doc
master       0.0.127.in-addr.arpa      named.local
master       6.45.123.in-addr.arpa     doc.rev
;This system is also the slave for the sales.doc.com domain
slave     sales.doc.com             111.22.3.4   db.sales
slave     3.22.111.in-addr.arpa     111.22.3.4   sales.rev
 

Example 5–2 Example Boot File for dnssales Server

; named.boot file on the dnssales (altair)
; 
; in.named is located here
directory /var/named
; here are the names of the master files
cache      .                        named.ca
master    sales.doc.com            db.sales
master    0.0.127.in-addr.arpa     db.127.0.0
master    3.22.111.in-addr.arpa    db.192.168.8

Example 5–3 Example Boot File for dnssecond Server

; named.boot file on the dnsecond (deneb)
directory /var/named
cache           .               named.ca
slave       doc.com         123.45.6.1 doc.com
slave       6.45.123.in-addr.arpa    123.45.6.1 doc.123.45.6

Example resolv.conf Files

The following code examples show resolv.conf files for the three servers in the two networks. (If the host in question is not running in.named, the local host address should not be used as a name server.)

Example 5–4 Example resolve.conf File for dnsmastr Server

;
; /etc/resolv.conf file for dnsmaster (sirius)
;
domain           doc.com
nameserver       0.0.0.0
nameserver       111.22.3.5

Example 5–5 Example resolve.conf File for dnssales Server

;
; /etc/resolv.conf file for dnssales (altair)
;
domain           sales.doc.com
nameserver       111.22.3.4
nameserver       123.45.6.1

Example 5–6 Example resolve.conf File for dnssecond Server

;
; /etc/resolv.conf for dnssecond
;
domain           doc.com
nameserver       111.22.3.5
nameserver       123.45.6.1

Example named.local File

The following code example shows the named.local file used by the two master servers on the two networks. Both servers have the same file.

Example 5–7 Example named.local File for Both master Servers

; SOA rec
0.0.127.in-addr.arpa. IN SOA siriusdoc.com. sysop.centauri.doc.com.(
                          19970331    ; serial number
                          10800       ; refresh every 3 hours
                          10800       ; retry every 3 hours
                          604800      ; expire after a week
                          86400 )     ; TTL of 1 day
; Name Servers
0.0.127.in-addr.arpa.  IN  NS   sirius.doc.com.
0.0.127.in_addr.arpa   IN  NS   dnssecond.doc.com
1  IN  PTR localhost.

Example hosts Files

The following code examples show db.doc and db.sales files for the two master servers on the two networks.

Example 5–8 Example db.doc File for dnsmastr server

; SOA rec
doc.com. IN SOA sirius.doc.com. sysop.centauri.doc.com. (
                          19970332    ; serial number
                          10800       ; refresh every 3 hours
                          10800       ; retry every 3 hours
                          604800      ; expire after a week
                          86400 )     ; TTL of 1 day
; Name Servers
doc.com.               IN  NS  sirius.doc.com.
sales.doc.com.         IN  NS  altair.sales.doc.com.
; Addresses
localhost              IN  A  127.0.0.1
sirius                 IN  A  123.45.6.1
rigel                  IN  A  123.45.6.112
antares                IN  A  123.45.6.90
polaris                IN  A  123.45.6.101
procyon                IN  A  123.45.6.79
tauceti                IN  A  123.45.6.69
altair.sales.doc.com.   N  A   111.22.3.4
; aliases
dnsmastr               IN  CNAME    sirius.doc.com.
dnssecond.doc.com      IN  CNAME   deneb.doc.com

Example 5–9 Example db.sales File for dnssales server

; SOA rec
sales.doc.com.  IN SOA altair.sales.doc.com. sysop.polaris.doc.com. (
                           19970332    ; serial number
                           10800          ; refresh every 3 hours
                           10800          ; retry every 3 hours
                           604800        ; expire after a week
                           86400 )        ; TTL of 1 day
; Name Servers
doc.com.                IN  NS  sirius.doc.com.
sales.doc.com.          IN  NS  altair.sales.doc.com.
; Addresses
altair                  IN  A  111.22.3.4
localhost               IN  A  127.0.0.1
sirius.doc.com.         IN  A  123.45.6.1
luna                    IN  A  192.168.8.22
phoebus                 IN  A  192.168.8.24
deimos                  IN  A  192.168.8.25
ganymede                IN  A  192.168.8.27
europa                  IN  A  192.168.8.28
callisto                IN  A  192.168.8.29
; 
; aliases
dnssales.sales.doc.com  IN  CNAME    altair.sales.doc.com

Example hosts.rev Files

The following code examples show hosts.rev files for the two master servers on the two networks:

Example 5–10 Example doc.rev File for dnsmastr server

; SOA rec
6.45.123.in-addr.arpa.  IN SOA sirius.doc.com. sysop.centauri.doc.com. (
                           19970331    ; serial number
                           10800       ; refresh every 3 hours
                           10800       ; retry every 3 hours
                           604800      ; expire after a week
                           86400 )     ; TTL of 1 day
; Name Servers
6.45.123.in-addr.arpa.  IN  NS  sirius.doc.com.
;Pointer records for 123.45.6
1                       IN  PTR sirius.doc.com.
112                     IN  PTR rigel.doc.com.
90                      IN  PTR antares.doc.com. 
101                     IN  PTR polaris.doc.com. 
79                      IN  PTR procyon.doc.com.
69                      IN  PTR tauceti.doc.com.

Example 5–11 Example hosts.rev File for dnssales Server

; SOA rec
3.22.111.in-addr.arpa.  IN SOA altair.sales.doc.com. \
sysop.polaris.doc.com.(
                           19970331    ; serial number
                           10800       ; refresh every 3 hours
                           10800       ; retry every 3 hours
                           604800      ; expire after a week
                           86400 )     ; TTL of 1 day
; Name Servers
3.22.111.in-addr.arpa.  IN  NS  altair.sales.doc.com.; \
Pointer records for 111.22.3
22                      IN  PTR  luna
23                      IN  PTR  deneb
24                      IN  PTR  phoebus
25                      IN  PTR  deimos
26                      IN  PTR  altair
27                      IN  PTR  ganymede
28                      IN  PTR  europa
29                      IN  PTR  callisto

Example name.ca File

The following code example shows the named.ca file that is stored on each of the two master servers on the two networks. Both servers use identical named.ca files.

Example 5–12 Example named.ca File

;
; formerly NS1.ISI.EDU
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107
;
; formerly C.PSI.NET
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
;
; formerly TERP.UMD.EDU
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
;
; formerly NS.NASA.GOV
;.                       3600000      NS    E.ROOT-SERVERS.NET.
 
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
;
; formerly NS.ISC.ORG
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
;
; formerly NS.NIC.DDN.MIL
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
;
; formerly NIC.NORDU.NET
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
;
; temporarily housed at NSI (InterNIC)
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     198.41.0.10
;
; temporarily housed at NSI (InterNIC)
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     198.41.0.11
;
; temporarily housed at ISI (IANA)
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     198.32.64.12
;
; temporarily housed at ISI (IANA)
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     198.32.65.12
; End of File

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.

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.

Domains and Subdomains

Like the UNIX^TM 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.

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.

named.conf Statements

The named.conf file contains statements and comments. Statements end with a semicolon. Some statements can contain a contain a block of statements. Again, each statement in the block is terminated with a semicolon.

The named.conf file supports the following statements.

Example 5–13 Example Master Configuration File for a master server

options {
         directory "/var/named";
         datasize 2098;
         forward only;
         forwarders {
                  99.11.33.44;
         };
         recursion no;
         transfers-in 10;
         transfers-per-ns 2;
         allow-transfer {
                  127.0.1.1/24;
         };
};

logging {
         category queries { default_syslog; };
};

include "/var/named/abcZones.conf"

// here are the names of the master files
zone "cities.zn" {
         type master;
         file "db.cities.zn";
};

zone "0.0.127.in-addr.arpa." {
         type master;
         file "db.127.cities.zn";
};

zone "168.192.in-addr.arpa" {
         type master;
         file "db.cities.zn.rev";
};

zone "sales.doc.com" {
         type slave;
         file "slave/db.sales.doc";
         masters {
                  192.168.1.151;
         };
};

zone "168.192.in-addr.arpa" {
         type slave;
         file "slave/db.sales.doc.rev";
         masters {
                  192.168.1.151;
         };
};

The named.ca File

The named.ca file establishes the names of root servers and lists their addresses. If your network is connected to the Internet, named.ca lists the Internet name servers; otherwise, it lists the root domain name servers for your local network. The in.named daemon cycles through the list of servers until it contacts one of them. It then obtains from that server the current list of root servers, which it uses to update named.ca.

Setting Up the named.ca File

Root server names are indicated in the NS record and addresses in the A record. You need to add an NS record and an A record for each root server you want to include in the file.

How you obtain or create your named.ca file depends on whether or not your network is connected to the world Internet.

Internet named.ca File

If your network is connected to the Internet, at the present time you obtain your named.ca file from InterNIC registration services through the following.

• Anonymous FTP. The FTP site is: ftp.rs.internic.net. The file name is: /domain/named.root.

• Gopher. The Gopher site is: rs.internic.net. The file is: named.root, which can be found under the InterNIC Registration Services menu, InterNIC Registration Archives submenu.

If you are following the naming conventions used in this manual, you then move named.root to /var/named/named.ca.

Example 5–14 Example Internet named.ca file

;
; formerly NS1.ISI.EDU
.                        3600000    NS   B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000    A    128.9.0.107
;
; formerly C.PSI.NET
.                        3600000    NS   C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000    A    192.33.4.12
;
; formerly TERP.UMD.EDU
.                        3600000    NS   D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000    A    128.8.10.90
;
; formerly NS.NASA.GOV
;.                       3600000    NS   E.ROOT-SERVERS.NET.
 
E.ROOT-SERVERS.NET.      3600000    A    192.203.230.10
;
; formerly NS.ISC.ORG
.                        3600000    NS   F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000    A    192.5.5.241
;
; formerly NS.NIC.DDN.MIL
.                        3600000    NS   G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000    A    192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
.                        3600000    NS   H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000    A    128.63.2.53
;
; formerly NIC.NORDU.NET
.                        3600000    NS   I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000    A    192.36.148.17
;
; temporarily housed at NSI (InterNIC)
.                        3600000    NS   J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000    A    198.41.0.10
;
; temporarily housed at NSI (InterNIC)
.                        3600000    NS   K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000    A    198.41.0.11
;
; temporarily housed at ISI (IANA)
.                        3600000    NS   L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000    A    198.32.64.12
;
; temporarily housed at ISI (IANA)
.                        3600000    NS   M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000    A    198.32.65.12
; End of File

Non-Internet named.ca File

If your network is not connected to the Internet, you create your own named.ca file. To do this, you designate one of your servers to be the root server, then create a named.ca file on every DNS server pointing to that root server.

For example, suppose your domain is named private and you designate the machine ourroot as your non-Internet root server. The ourroot machine has an IP address of 192.1.1.10. Your named.ca files would then contain the line:

ourroot.private.  999999  IN  A  192.1.1.10

Cache files also need an SOA record, NS records for each domain and subdomain, and A records for each server.

For example, suppose that in addition to ourroot you also had DNS name servers called ourmaster and ourslave. The named.ca files on all of your DNS servers would then look like the following.

Example 5–15 Sample named.ca File (Non-Internet)

;
@    IN    SOA  ourroot.private.   hermit.ourroot.private  (    
                 1997071401       ;  serial number (YYYYMMDD##)
                 10800            ;  refresh after 3 hours
                 3600             ;  retry after 1 hour
                 604800           ;  expire after 1 week
                 86400 )          ;  minimum TTL of 1 day
;
ourroot.private.      999999     IN    A    192.1.1.10
;
private.                         IN    NS   ourmaster.private.
1.1.192.in-addr.arpa             IN    NS   ourmaster.private.
 
ourprivate.private.              IN    A    192.1.1.1
;
private.                         IN    NS   ourslave.private.
1.1.192.in-addr.arpa             IN    NS   ourslave.private.
ourslave.private.            IN    A    192.1.1.2 

The hosts File

The hosts file contains all the data about the machines in the local zone. The name of this file is specified in the boot file. To avoid confusion with /etc/hosts, name the file something other than hosts, for example, you could name these files using the pattern db.domain. Using that nomenclature, the host files for the doc.com and sales.doc.com domains might be db.doc and db.sales.

Setting Up the hosts File

The hosts file contains all the data about every machine in your zone. If a zone covers more than one domain, all machines in all the domains covered by the zone are listed in the zone's host file. See Setting Up the hosts File.

The name hosts is a generic name indicating the file's purpose and content. But to avoid confusion with /etc/hosts, you should name this file something other than hosts. If you have more than one zone, each zone must have its own hosts file and each of these zone hosts files must have a unique name. For example, if your DNS domain is divided into doc.com and sales.doc.com zones, you could name one hosts file db.doc and the other sales.db.doc.

There must be a separate, uniquely named, hosts file for each zone. If you have more than one zone, each zone's host file must include information about the master (master and slave) servers of the other zones, as described in Example 5–16.

Example 5–16 Sample hosts File

;
; SOA rec
doc.com.  IN SOA sirius.doc.com. sysop.centauri.doc.com. (
                 1997071401       ;  serial number (YYYYMMDD##)
                      10800       ;  refresh every 3 hours
                      10800       ;  retry every 3 hours
                      604800      ;  expire after a week
                      86400 )     ;  TTL of 1 day
; Name Servers
doc.com.                   IN  NS  sirius.doc.com.
sales.doc.com.             IN  NS  altair.sales.doc.com.
; Addresses
localhost.                 IN  A  127.0.0.1
 
sirius                    IN  A  192.168.6.1
rigel                     IN  A  192.168.6.112
antares                   IN  A  192.168.6.90
polaris                   IN  A  192.168.6.101
procyon                   IN  A  192.168.6.79
tauceti                   IN  A  123.45.6.69
altair.sales.doc.com.     IN  A   111.22.3.4
; aliases
durvasa                   IN  CNAME sirius.doc.com.
dnsmastr                  IN  CNAME sirius.doc.com.
dnssales                  IN  CNAME altair.sales.doc.com.

A hosts file usually contains these elements:

• A Start of Authority (SOA) record

• One or more Name Server (NS) records identifying master and slave DNS name servers

• Address (A) records for each host in the zone

• Canonical Name (CNAME) records for each host alias in the zone

• One or more Mail Exchange (MX) records

The hosts.rev File

The hosts.rev file specifies a zone in the in-addr.arpa. domain, the special domain that allows reverse (address-to-name) mapping. The name of this file is specified in the boot file.

Setting Up the hosts.rev File

The hosts.rev file sets up inverse mapping.

The name hosts.rev is a generic name indicating the file's purpose and content. If you have more than one zone, each zone must have its own hosts.rev file and each of these zone hosts.rev files must have a unique name. For example, if your DNS domain is divided into doc.com and sales.doc.com zones, you could name one hosts.rev file doc.rev and the other sales.rev.

Example 5–17 Sample hosts.rev File

; SOA rec
6.45.123.in-addr.arpa.  IN SOA sirius.doc.com. sysop.centauri.doc.com. (
                 1997071401       ;  serial number (YYYYMMDD##)
                      10800       ;  refresh every 3 hours
                      10800       ;  retry every 3 hours
                      604800      ;  expire after a week
                      86400 )     ;  TTL of 1 day
; Name Servers
6.45.123.in-addr.arpa.   IN  NS  sirius.doc.com.
1                        IN  PTR sirius.doc.com.

A hosts.rev file contains the following elements.

• A Start of Authority (SOA) record

• One or more Name Server (NS) records identifying master and slave DNS name servers. Server names should be fully qualified.

• A PTR record for each host in the zone. Machine names should be fully qualified.

(See Resource Record Types for detailed descriptions of these resource record types.)

The named.local File

The named.local file specifies the address for the local loopback interface, or localhost, with the network address 127.0.0.1. The name of this file is specified in the boot file. Like other files, you can give it a name other than the name used in this manual.

Setting Up the named.local File

The named.local file sets up the local loopback interface for your name server.

Example 5–18 Sample named.localFile

; SOA rec
0.0.127.in-addr.arpa. IN SOA sirius.doc.com sysop.centauri.doc.com (
                          1997071401       ;  serial number (YYYYMMDD##)            
                           10800           ;  refresh every 3 hours
                           10800           ;  retry every 3 hours
                           604800          ;  expire after a week
                           86400 )         ;  TTL of 1 day
; Name Servers
0.0.127.in-addr.arpa.      IN  NS     sirius.doc.com
1                          IN  PTR  localhost.
 

A named.local file contains these elements:

• A Start of Authority (SOA) record, which indicates the start of a zone and includes the name of the host on which the named.local data file reside.

• One or more Name Server (NS) records identifying master and slave DNS name servers. Server and domain names should be fully qualified.

• A PTR record for localhost

$INCLUDE Files

An include file is any file named in an $INCLUDE() statement in a DNS data file. $INCLUDE files can be used to separate different types of data into multiple files for your convenience.

For example, suppose a data file contained following line:

$INCLUDE /etc/named/data/mailboxes

This line causes the /etc/named/data/mailboxes file to be loaded at that point. In this instance, /etc/named/data/mailboxes is an $INCLUDE file. Use of $INCLUDE files is optional. You can use as many as you wish, or none at all.

Data File Resource Record Format

All the data files used by the DNS daemon in.named are written in standard resource record format. Each DNS data file must contain certain resource records. This section describes the DNS data files and the resource records each file should contain.

Standard Resource Record Format

In the standard resource record format, each line of a data file is called a resource record (RR), which contains the following fields separated by white space:

namettlclassrecord-typerecord-specific-data

The order of the fields is always the same; however, the first two are optional (as indicated by the brackets), and the contents of the last vary according to the record-type field.

The name Field

The first field is the name of the domain that applies to the record. If this field is left blank in a given RR, it defaults to the name of the previous RR.

A domain name in a zone file can be either a fully qualified name, terminated with a dot, or a relative name, in which case the current domain is appended to it.

The ttl Field

The second field is an optional time-to-live field. This specifies how long (in seconds) this data will be cached in the database before it is disregarded and new information is requested from a server. By leaving this field blank, the ttl defaults to the minimum time specified in the Start-Of-Authority (SOA) resource record.

If the ttl value is set too low, the server will incur a lot of repeat requests for data refreshment; if, on the other hand, the ttl value is set too high, changes in the information will not be timely distributed.

Most ttl values should be initially set to between a day (86400) and a week (604800). Then, depending on the frequency of actual change of the information, you can change the appropriate ttl values to reflect that frequency. Also, if you have some ttl values that have very high numbers because you know they relate to data that rarely changes. When you know that the data is now about to change, reset the ttl to a low value (3600 to 86400) until the change takes place. Then change it back to the original high value.

All RR's with the same name, class, and type should have the same ttl value.

The class Field

The third field is the record class. Only one class is currently in use: IN for the TCP/IP protocol family.

The record-type Field

The fourth field states the resource record type. There are many types of RR's; the most commonly used types are discussed in Resource Record Types.

The record-specific-data Field

The contents of the record-specific-data field depend on the type of the particular resource record.

Although case is preserved in names and data fields when loaded into the name server, all comparisons and lookups in the name server database are case insensitive. However, this situation might change in the future; thus, you should be consistent in your use of lower and uppercase.

Special Resource Record Characters

The following characters have special meanings:

Most resource records have the current origin appended to names if they are not terminated by a dot (.). This is useful for appending the current domain name to the data, such as machine names, but might cause problems when you do not want this to happen. You should use a fully qualified name ending in a period if the name is not in the domain for which you are creating the data file.

Control Entries

The only lines that do not conform to the standard RR format in a data file are control-entry lines. There are two kinds of control entries: $INCLUDE() and $ORIGIN().

$INCLUDE

An include line begins with $INCLUDE in column 1, and is followed by a file name (known as the $INCLUDE file). This feature is particularly useful for separating different types of data into multiple files as in this example:

$INCLUDE /etc/named/data/mailboxes

The line is interpreted as a request to load the /etc/named/data/mailboxes file at that point. The $INCLUDE command does not cause data to be loaded into a different zone or tree. The command allows for data for a given zone to be organized in separate files. For example, mailbox data might be kept separately from host data using this mechanism.

Use of $INCLUDE statements and files is optional. You can use as many as you wish, or none at all.

$ORIGIN()

The $ORIGIN command is a way of changing the origin in a data file. The line starts in column 1, and is followed by a domain name. It resets the current origin for relative domain names (for example, not fully qualified names) to the stated name. This is useful for putting more than one domain in a data file.

You cannot use $ORIGIN() for putting more than one zone in a data file.

Use of $ORIGIN commands in a data file is optional. If there is no $ORIGIN() statement the default origin for DNS data files is the domain named in the second field of the master or slave line of the named.conf file.

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.

Start-of-Authority record (SOA)

Example 5–19 shows the syntax of a start-of-authority (SOA) resource record.

Example 5–19 SOA Record Format

name class SOA origin person-in-charge ( serial number
	 refresh
 retry
 expire
 ttl)		 

The SOA record designates the start of a zone. The zone ends at the next SOA record. The SOA record fields are described below.

name

This field indicates the name of the zone. Note that the zone name must end with a trailing dot. For example: doc.com. is correct, while doc.com is wrong.

class

This field is the address class. For example, IN for Internet (the most commonly used class).

SOA

This field is the type of this resource record.

origin

This field is the name of the host where this data file resides. Note that this host name must end in a trailing dot. For example, dnsmaster.doc.com. is correct, but dnsmaster.doc.com is wrong.

person-in-charge

This field is the email address of the person responsible for the name server. For example, kjd.nismaster.doc.com. Again, this name must end with a trailing dot.

serial

This field is the version number of this data file. You must increment this number whenever you make a change to the data: slave servers use the serial field to detect whether the data file has been changed since the last time they copied the file from the master server.

refresh

This field indicates how often, in seconds, a slave name server should check with the master name server to see if an update is needed. For example, 7200 indicates a period of two hours.

retry

This field indicates how long, in seconds, a slave server is to retry after a failure to check for a refresh.

expire

This field is the upper limit, in seconds, that a slave name server is to use the data before it expires for lack of getting a refresh.

ttl

This field is the default number of seconds to be used for the time-to-live field on resource records that do not have a ttl specified elsewhere.

There should only be one SOA record per zone. Example 5–20 is a sample SOA resource record.

Example 5–20 Sample SOA Resource Record

;name class 		SOA 	origin				 person-in-charge
doc.com. IN		SOA	dnsmaster.doc.com. root.nismaster.doc.com. (
							101			;Serial
							7200		;Refresh
							3600		;Retry
							432000		;Expire	
							86400)		;Minimum			 )

Name Server (NS)

Example 5–21 shows the syntax of a name-server (NS) resource record:

Example 5–21 NS Record Format

domainname [optional TTL] class NS name-server-name

The name-server record lists by name a server responsible for a given domain. The name field lists the domain that is serviced by the listed name server. If no name field is listed, then it defaults to the last name listed. One NS record should exist for each master and slave server for the domain. Example 5–22 is a sample NS resource record.

Example 5–22 Sample NS Resource Record

;domainname    [TTL] 	 class	NS	nameserver	
doc.com        90000     IN	NS 	sirius.doc.com.

Address (A)

Example 5–23 shows the syntax of an address (A) resource record:

Example 5–23 Address Record Format

	
machinename	[optional TTL] class A	address

The A record lists the address for a given machine. The name field is the host name, and the address is the IP address. One A record should exist for each address of the machine (in other words, routers, or gateways require at least two entries, a separate entry including the IP address assigned to each network interface).

Example 5–24 Sample Address Record

;machinename	[TTL]	class	A	address
sirius		IN		A	123.45.6.1

Host Information (HINFO)

Example 5–25 shows the syntax of a host-information (HINFO) resource record:

Example 5–25 HINFO Record Format

[optional name] [optional TTL] 	class	HINFO hardware	OS

The HINFO contains host-specific data. It lists the hardware and operating environment that are running at the listed host. If you want to include a space in the machine name or in the entry in the hardware field, you must surround the entry with quotes. The name field specifies the name of the host. If no name is specified, it defaults to the last in.named host. One HINFO record should exist for each host. Example 5–26 is a sample HINFO resource record.

Example 5–26 Sample HINFO Resource Record

;[name]   [TTL] class HINFO   hardware    OS
                IN    HINFO   Sparc-10    UNIX

Because the HINFO field provides information about the machines on your network, many sites consider it a security risk and no longer use it.

Well-Known Services (WKS)

Example 5–27 shows the syntax of a well-known services (WKS) resource record:

Example 5–27 WKS Record Format

[Optional name] [TTL] class WKS address protocol-list-of-services

The WKS record describes the well-known services supported by a particular protocol at a specified address. The list of services and port numbers come from the list of services specified in the services database. Only one WKS record should exist per protocol per address. Example 5–28 is an example of a WKS resource record.

Example 5–28 Sample WKS Resource Record

;[name]	[TTL]	class	WKS	address 	 protocol-list-of-services
altair		IN	WKS	123.45.6.1	 TCP ( smtp discard rpc
 sftp uucp-path systat daytime
 netstat qotd nntp doc.com )

The WKS record is optional. For security reasons, most sites no longer provide this information.

Canonical Name (CNAME)

Example 5–29 shows the syntax of a canonical-name (CNAME) resource record.

Example 5–29 CNAME Record Format

 nickname [optional TTL] class CNAME	canonical-name

The CNAME specifies a nickname or alias for a canonical name. A nickname should be unique. All other resource records should be associated with the canonical name and not with the nickname. Do not create a nickname and then use it in other resource records. Nicknames are particularly useful during a transition period, when a machine's name has changed but you want to permit people using the old name to reach the machine. Nicknames can also be used to identify machines that serve some specific purpose such as a mail server. Example 5–30 is a sample CNAME resource record.

Example 5–30 Sample CNAME Resource Record

;nickname      [TTL]	class	CNAME	canonical-name
mailhost		IN	CNAME	antares.doc.com

Pointer Record (PTR)

Example 5–31 shows the syntax for a PTR resource record.

Example 5–31 PTR Record Format

 special-name	[optional TTL]  class	 PTR-real-name

A pointer record allows special names to point to some other location in the domain. In the example, PTRs are used mainly in the in-addr.arpa. records for the translation of an address (the special name) to a real name. When translating an address, if the domain is fully qualified only the machine identification number need be specified. PTR names should be unique to the zone. The PTR records Example 5–32 sets up reverse pointers for the special in-addr.arpa domain.

Example 5–32 Sample PTR Resource Record

;special name   [TTL]	class	PTR-real-name
1			IN	PTR sirius.doc.com.

Mail Exchanger (MX)

Example 5–33 shows the syntax for a mail-exchanger (MX) resource record.

Example 5–33 MX Record Format

name [optional TTL] class	MX preference-value mailer-exchanger

The MX resource records are used to specify a machine that knows how to deliver mail to a domain or specific machines in a domain. There might be more than one MX resource record for a given name. In Example 5–34, Seismo.CSS.GOV. (note the fully qualified domain name) is a mail gateway that knows how to deliver mail to Munnari.OZ.AU. Other machines on the network cannot deliver mail directly to Munnari. Seismo and Munnari might have a private connection or use a different transport medium. The preference-value field indicates the order a mailer should follow when there is more than one way to deliver mail to a single machine. The value 0 (zero) indicates the highest preference. If there is more than one MX resource record for the same name, records might or might not have the same preference value.

You can use names with the wildcard asterisk (*) for mail routing with MX records. There are likely to be servers on the network that state that any mail to a domain is to be routed through a relay. In Example 5–34, all mail to hosts in domain foo.com is routed through RELAY.CS.NET. You do this by creating a wildcard resource record, which states that the mail exchanger for *.foo.com is RELAY.CS.NET. The asterisk will match any host or subdomain of foo.com, but it will not match foo.com itself.

Example 5–34 Sample MX Resource Record

;name	 	[TTL]	class		MX	 preference mailer-exchanger
Munnari.OZ.AU.		IN		MX	 0	Seismo.CSS.GOV.
foo.com.		IN		MX	 10	RELAY.CS.NET.
*.foo.com.		IN		MX	 20	RELAY.CS.NET.