Introduction to Boot and Data Files

In addition to the in.named daemon, DNS on a name server consists of a boot file and local data files.

The location of the boot file is /etc/named.boot. (See "Setting Up the Boot File" on page 172 and Code Example 12-1 through Code Example 12-3 starting on page 172.) The boot file contains a list of domain names and the file names containing host information. Common names for the local data files are:

• named.ca - See "Setting Up the named.ca File" on page 180 and Code Example 12-4 on page 180.
• hosts - See "Setting Up the hosts File" on page 180 and Code Example 12-5 on page 181.
• hosts.rev - See "Setting Up the hosts.rev File" on page 189 and Code Example 12-22 on page 189.
• named.local - See "Setting Up the named.local File" on page 189 and Code Example 12-23 on page 190.

These names are used in the descriptions of these files that follow. However, you can name these files whatever you wish.

The named.boot File

The boot file named.boot establishes the server as a primary, secondary, or caching-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 boot file is read by in.named when the daemon is started by the server's start up script, /etc/init.d/inetsvc. The boot file directs in.named either to other servers or to local data files for a specified domain. (See "Setting Up the Boot File" on page 172 and Code Example 12-1 through Code Example 12-3 starting on page 172.)

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.

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/inet/hosts, name the file something other than hosts. In the sample boot file shown in Code Example 12-1, the hosts file is called mydomain.zone.

(See "Setting Up the hosts File" on page 180 and Code Example 12-5 on page 181.)

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. In the sample boot file shown in Code Example 12-1, the file is called mydomain.zone.rev.

(See "Setting Up the hosts.rev File" on page 189 and Code Example 12-22 on page 189.)

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 book. (See "Setting Up the named.local File" on page 189 and Code Example 12-23 on page 190.)

Setting Up the Boot File

The contents of the boot file varies, depending on the type of server. This section describes boot files for primary, secondary, and caching-only servers.

The server's initialization script, /etc/init.d/inetsvc, expects the name /etc/named.boot when it looks for the in.named daemon boot file. The script will not start the daemon if you name the boot file something else.

Code Example 12-1 shows a sample boot file for a primary server.

Code Example 12-1 Master Boot File for Primary Server

; ; Sample named.boot file for Primary Master Name Server ; ; type domain source file or host ; directory /var/named cache . named.ca primary university.edu. mydomain.zone primary 32.128.in-addr.arpa. mydomain.zone.rev primary 0.0.127.in-addr.arpa named.local

The entries in the file are explained below.

The directory Line

The directory line in the boot file designates the directory in which you want the name server to run:

directory /var/named

This allows the use of relative path names for the files mentioned in the boot file or, later, with the $INCLUDE directive. This feature is especially useful if you have many files to be maintained, and you want to locate them all in one directory dedicated to that purpose.

If there is no directory line in the boot file, all file names listed in the boot file must be full path names.

The cache Line

A name server needs to know which servers are the authoritative name servers for the root zone. To do this, you have to list the addresses of these higher authorities.

All servers should have the following line in the boot file to find the root name servers:

cache . named.ca

The first field(.) indicates that the server will obtain root servers hints from the indicated file, in this case, named.ca (located in the directory /var/named).

The primary Lines

To set up a primary server, you must create a file that contains all the authoritative data for the zone. Then create a boot file that designates the server as a primary server and tells it where to find the authoritative data.

The following line in the boot file names the server and the data file:

primary university.edu. mydomain.zone

The first field designates the server as primary for the zone university.edu, as stated in the second field. The third field contains the name of the file from which authoritative data is read, in this case mydomain.zone.

The lines:

primary 32.128.in-addr.arpa. mydomain.zone.rev primary 0.0.127.in-addr.arpa. named.local

indicate that the server is also a primary server for the zone 32.128.in-addr.arpa. (that is, the reverse address domain for university.edu) and 0.0.127.in-addr.arpa. (reverse address for the local host loopback). Data for them is to be found, respectively, in the files mydomain.zone.rev and named.local.

Code Example 12-2 is a sample boot file for a secondary server in the same domain as the above primary server.

Code Example 12-2 Sample Master Boot File for Secondary Server

; ; Sample named.boot file for secondary master name server ; ; type domain source file or host ; directory /var/named cache .named . ca secondary university.edu. 128.32.0.4 128.32.0.10 123.32.136.22 mydomain.zone.zone secondary 32.128.in-addr.arpa 128.32.0.4 128.32.0.10 128.32.136.22 purev.zone primary 0.0.127.in-addr.arpa named.local

In appearance, this file is very similar to the boot file for the primary server; the main difference is to be found in the lines:

secondary university.edu. 128.32.0.4 128.32.0.10 128.32.136.22 mydomain.zone.zone secondary 32.128.in-addr.arpa 128.32.0.4 128.32.0.10 128.32.136.22 purev.zone

The word secondary establishes that this is a secondary server for the zone listed in the second field. It is to get its data from the listed servers (usually the primary server followed by one or more secondaries). Attempts to obtain data are made in the order in which the servers are listed. If there is a file name after the list of servers, as in the example above, data for the zone will be put into that file as a backup. When the secondary server is started, data is loaded from the backup file, if it exists. Then one of the servers is consulted to check whether the data is still up to date.

This ability to specify multiple secondary IP addresses allows for great flexibility in backing up a zone.

---

Note - A server may act as the primary server for one or more zones, and as the secondary server for one or more zones. The mixture of entries in the boot file determines whether a server is a primary or secondary.

---

The interpretation of the other secondary line is similar to the above. Note also that although this machine is a secondary server for the domain university.edu. and 32.128.in-addr.arpa., it is a primary server for 0.0.127.in-addr.arpa. (the local host). Code Example 12-3 is a sample boot file for a caching-only server.

Code Example 12-3 Sample Master Boot File for Caching-only Server

; ; Sample named.boot file for caching-only name server ; ; type domain source file or host ; cache . named.ca primary 0.0.127.in-addr.arpa named.local

You do not need a special line to designate a server as a caching-only server. What denotes a caching-only server is the absence of authority lines, such as secondary or primary, in the boot file. As explained on page 165, a caching-only server does not maintain any authoritative data; it simply handles queries and asks the hosts listed in the in.named file for the information needed.

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. This section describes the DNS data files and the resource records each file should contain. The section "Standard Resource Record Format" discusses standard resource record format, including an explanation of each resource record relevant to the DNS data files. It is followed by descriptions of the DNS data files.

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:

<name> <ttl> class record-type record-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" on page 179.

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 may 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:

Table 12-1

Character	Definition
.	A free-standing dot in the name field refers to the current domain.
@	A free-standing @ in the name field denotes the current origin.
..	Two free-standing dots represent the null domain name of the root when used in the name field.
\X	Where X is any character other than a digit (0-9), quotes that character so that its special meaning does not apply. For example, you can use \. to place a dot character in a label.
\DDD	Where each D is a digit, this is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning.

Table 12-1

Character	Definition
()	Use parentheses to group data that crosses a line. In effect, line terminations are not recognized within parentheses.
;	A semicolon starts a comment; the remainder of the line is ignored.
*	An asterisk signifies a wildcard.

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 may 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. 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. This is simply a way to allow 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.

$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.

Resource Record Types

The most commonly used types of resource records are listed in Table 12-2. They are usually entered in the order shown in Table 12-2, but that is not a requirement.

Table 12-2

Type	Description
SOA	start of authority
NS	name server
A	Internet address (name to address)
PTR	pointer (address to name)
CNAME	canonical name (nickname)
TXT	text information
WKS	well-known services
HINFO	host information
MX	mail exchanger

Code Example 12-5 on page 181 shows an example of a hosts file. It is presented here for illustration purposes only. Explanations of each field follow the code example. In that sample file @ indicates the current zone or origin and lines that begin with a semicolon (;) are comments.

Setting Up the named.ca File

The named.ca file contains the names and addresses of the root servers. 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. Code Example 12-4 is a sample named.ca file.

Code Example 12-4 Sample named.ca File

; ;Initial cache data for root domain servers. ; ; list of servers... 99999999 IN NS NIC.DDN.MIL. 99999999 IN NS A.ISI.EDU. 99999999 IN NS TERP.UMD.EDU. 99999999 IN NS C.NYSER.NET. ; ; ...and their addresses NIC.DDN.MIL. 99999999 IN A 26.0.0.73 C.NYSER.NET. 99999999 IN A 192.33.4.12 NS.NASA.GOV. 99999999 IN A 128.102.16.10 A.ISI.EDU. 99999999 IN A 26.3.0.103

Setting Up the hosts File

The hosts file contains all the data about every machine in your zone. This information includes server names, IP addresses, host information (hardware and operating system information), canonical names and aliases, the services supported by a particular protocol at a specific address, and group and user information related to mail services. This information is represented in the records NS, A, CNAME, HINFO, WKS, PRT, and MX records. The file also includes the SOA record, which indicates the start of a zone and includes the name of the host on which the hosts data file resides.

Code Example 12-5 shows a sample hosts file.

Code Example 12-5 Sample hosts File

; sample hosts file @ IN SOA ourlima.Sample.Edu. root.sendai.Sample.Edu. 101 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS ourarpa.Sample.Edu. IN NS ourlima.Sample.Edu. ourarpa IN A 128.32.0.4 IN A 10.0.0.78 ; The HINFO field is a sample for syntax only ; IN HINFO 3B2 UNIX arpa IN CNAME ourarpa seattle IN A 128.32.0.6 ; IN HINFO Sun 4/75 Solaris 2.5 ourseattle IN CNAME seattle sendai IN A 128.32.7 IN A 128.32.130.6 ; IN HINFO Sun-4/75 Solaris 2.5 oursendai IN CNAME sendai ourlima IN A 10.2.0.78 IN A 128.32.0.10 ; IN HINFO Sun-4/75 Solaris 2.5 IN WKS 128.32.0.10 UDP syslog route timed domain IN WKS 128.32.0.10 TCP ( echo telnet discard rpc sftp uucp-path systat daytime netstat qotd nntp link chargen ftp auth time whois mtp pop rje finger smtp supdup hostnames domain nameserver ) lima IN CNAME ourlima nairobi IN A 128.32.131.119 ; IN HINFO SPARC 2000 Solaris 2.5 nairobi IN MX 0 sendai.Sample.Edu.

SOA-- Start of Authority

Code Example 12-6 shows the syntax of a start-of-authority (SOA) resource record.

Code Example 12-6 SOA Record Format

name <ttl> <class> SOA origin person-in-charge ( serial refresh retry expire minimum )

The start-of-authority 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: Sample.edu. is correct, while Sample.edu 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, ourlima.Sample.edu. is correct, but ourlima.Sample.edu is wrong.

person-in-charge This field is the email address of the person responsible for the name server. For example, kjd.sendai.Sample.edu. 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: secondary 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 secondary name server should check with the primary 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 secondary server is to retry after a failure to check for a refresh.

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

minimum This field is the default number of seconds to be used for the time-to-live field on resource records that don't have a ttl specified.

There should only be one SOA record per zone. Code Example 12-7 is a sample SOA resource record.

Code Example 12-7 Sample SOA Resource Record

;name class SOA origin person-in-charge Sample.edu. IN SOA ourlima.Sample.Edu. root.sendai.Sample.Edu. 101 ;Serial 7200 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum

NS--Name Server

Code Example 12-8 shows the syntax of a name-server (NS) resource record:

Code Example 12-8 NS Record Format

<name> <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 primary and secondary master server for the domain. Code Example 12-9 is a sample NS resource record.

Code Example 12-9 Sample NS Resource Record

;<name> <ttl> class NS name-server-name IN NS ourarpa.Sample.Edu.

A--Address

Code Example 12-10 shows the syntax of an address (A) resource record:

Code Example 12-10 Address Record Format

<name> <ttl> class A address

The address 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 require at least two entries, a separate entry including the IP address assigned to each network interface).

Code Example 12-11 Sample Address Record

;<name> <ttl> class A address ourarpa IN A 128.32.0.4 IN A 10.0.0.78

HINFO--Host Information

Code Example 12-12 shows the syntax of a host-information (HINFO) resource record:

Code Example 12-12 HINFO Record Format

<name> <ttl> class HINFO hardware OS

The host-information resource record contains host-specific data. It lists the hardware and operating system 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. Code Example 12-13 is a sample HINFO resource record.

Code Example 12-13 Sample HINFO Resource Record

;<name> <ttl> class HINFO hardware OS IN HINFO Sun-4/80 UNIX

---

Caution - The HINFO field is considered a security hole and is seldom used.

---

WKS--Well-Known Services

Code Example 12-14 shows the syntax of a well-known services (WKS) resource record:

Code Example 12-14 WKS Record Format

<name> <ttl> class WKS address protocol-list-of-services

The well-known services 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. Code Example 12-15 is an example of a WKS resource record.

Code Example 12-15 Sample WKS Resource Record

;<name> <ttl> class WKS address protocol-list-of-services IN WKS 128.32.0.10 UDPwho route timed domain IN WKS 128.32.0.10 TCP (echo telnet discard rpc sftp uucp-path systat daytime netstat qotd nntp link chargen ftp auth time whots mtp pop rje finger smtp supdup hostnames domain nameserver)

The WKS record is optional. Most sites no longer provide this information.

CNAME--Canonical Name

Code Example 12-16 shows the syntax of a canonical-name (CNAME) resource record.

Code Example 12-16 CNAME Record Format

nickname <ttl> class CNAME canonical-name

The canonical-name resource record specifies a nickname 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. Code Example 12-17 is a sample CNAME resource record.

Code Example 12-17 Sample CNAME Resource Record

;nickname <ttl> class CNAME canonical-name oursendai IN CNAME sendai

PTR--Pointer Record

Code Example 12-18 shows the syntax for a pointer (PTR) resource record.

Code Example 12-18 PTR Record Format

special-name <ttl> class PTR-real-name

A pointer record allows special names to point to some other location in the domain. In the example, PTR's are used mainly in the in-addr.arpa. records for the translation of an address (the special name) to a real name. PTR names should be unique to the zone. The PTR records Code Example 12-19 sets up reverse pointers for the special in-addr.arpa. domain.

Code Example 12-19 Sample PTR Resource Record

;special name <ttl> class PTR-real-name 7.0 IN PTR sendai.university.edu. 2.2.18.128.in-addr.arpa. IN PTR blah.gull.com.

MX--Mail Exchanger

Code Example 12-20 shows the syntax for a mail-exchanger (MX) resource record.

Code Example 12-20 MX Record Format

name <ttl> class MX preference-valuemailer-exchanger

The mail-exchanger resource records are used to specify a machine that knows how to deliver mail to a domain or machines in a domain. There may be more than one MX resource record for a given name. In Code Example 12-21 on page 188, 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 may 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 may or may 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 simply state that any mail to a domain is to be routed through a relay. In Code Example 12-21, 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.

---

Note - If the MX record contains both a wildcard and an explicit resource record, the explicit record is used.

---

Code Example 12-21 Sample MX Resource Record

;name {ttl} class MX preference-value 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.

Setting Up the hosts.rev File

The hosts.rev file sets up inverse mapping. It must contain the names of the primary and master name servers in your local domain, plus pointers to those servers and to other, non-authoritative name servers. The names of the primary and secondary master servers are indicated by NS records, and the pointers are indicated by PTR records. The file also needs an SOA record to indicate the start of a zone and the name of the host on which hosts.rev resides. Code Example 12-22 on page 189 is a sample hosts.rev file.

Code Example 12-22 Sample hosts.rev File

; sample hosts.rev file @ IN SOA ourhost.university.edu. root.sendai.university.edu. ( 101 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS ourarpa.university.edu. IN NS ourhost.university.edu. 4.0 IN PTR ourarpa.university.edu. 6.0 IN PTR seattle.university.edu. 7.0 IN PTR sendai.university.edu 10.0 IN PTR ourhost.university.edu. 6.130 IN PTR sendai.university.edu.

Setting Up the named.local File

The named.local file sets up the local loopback interface for your name server. It must contain the host name of the machine, plus a pointer to the host name localhost, which represents the loopback mechanism. The server name is indicated in the NS resource record, and the pointer to localhost is indicated by the PTR record. The file must also include an SOA record, which

indicates the start of a zone and includes the name of the host on which the named.local data file reside. Code Example 12-23 is a sample named.local file.

Code Example 12-23 Sample named.local File

; sample named.local file @ IN SOA ourhost.university.edu. root.sendai.university.edu 1 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS ourhost.university.edu. 1 IN PTR localhost.

Modifying the Data Files

When you add or delete a host in one of the data files in the master DNS server or otherwise modify the data files, you must also change the serial number in the SOA resource record so the secondary servers modify their data accordingly; you should then inform in.named in the master server that it should reread the data files and update its internal database.

When in.named successfully starts, the daemon writes its process ID to the file /etc/named.pid. To have in.named reread named.boot and reload the database, type:

# kill -HUP 'cat /etc/named.pid'

Note that all previously cached data is lost, and the caching process starts over again.

---

Caution - Do not attempt to run in.named from inetd. This will continuously restart the name server and defeat the purpose of having a cache.

---

A Practical Example

You can now start building the files that an imaginary network would need. Assume that the network is composed of three networks, all with access to the Internet. Each network has a class C network number:

Table 12-3

Name	Number
gull	223.100.100
falcon	223.100.101
owl	223.100.102

The names of the zones are also the names of the hosts that are being designated as the master servers.

Further assume that after careful consideration you decide that you want to set up DNS in the network so that each master server is the primary server for its zone and a secondary server for the other zones. All these assumptions result in the following tables:

Table 12-4 gull

Host Name	Function	Address
gull	primary	223.100.100.1
falcon	secondary	223.100.101.1
owl	secondary	223.100.102.1
	hosts	223.100.100.2- 80

Table 12-5 falcon

Host Name	Function	Address
falcon	primary	223.100.101.1
gull	secondary	223.100.100.1
owl	secondary	223.100.102.1
	hosts	223.100.101.2- 110

Table 12-6 owl

Host Name	Function	Address
owl	primary	223.100.102.1
gull	secondary	223.100.100.1
falcon	secondary	223.100.101.1
	hosts	223.100.102.2- 156

Code Example 12-24 shows boot files for the three servers in the network.

Code Example 12-24 Example Network Server Boot Files

; Boot file for server gull directory /var/named cache . named.root primary gull.com. gull.zone primary 100.100.223.in-addr.arpa. gull.revzone primary 0.0.127.in-addr.arpa. named.local secondary falcon.gull.com. 223.100.101.1 223.100.102.1 falcon.zone secondary owl.gull.com. 223.100.101.1 223.100.102.1 owl.zone secondary 101.100.223.in-addr.arpa. 223.100.101.1 falcon.rev secondary 102.100.223.in-addr.arpa. 223.100.102.1 owl.rev

; ; Boot file for server falcon directory /var/named cache . named.root primary falcon.gull.com. falcon.zone primary 101.100.223.in-addr.arpa. falcon.revzone primary 0.0.127.in-addr.arpa. named.local secondary gull.com. 223.100.100.1 223.100.102.1 gull.zone secondary owl.gull.com. 223.100.100.1 223.100.102.1 owl.zone secondary 100.100.223.in-addr.arpa. 223.100.100.1 gull.rev secondary 102.100.223.in-addr.arpa. 223.100.102.1 owl.rev

;Boot file for server owl ; directory /var/name cache . named.root primary owl.gull.com. owl.zone primary 102.100.223.in-addr.arpa. owl.revzone primary 0.0.127.in-addr.arpa. named.local secondary gull.com. 223.100.100.1 223.100.102.1 gull.zone secondary falcon.gull.com. 223.100.100.1 223.100.101.1 falcon.zone secondary 100.100.223.in-addr.arpa. 223.100.100.1 gull.rev secondary 101.100.223.in-addr.arpa. 223.100.101.1 falcon.rev

The following are some sample resolv.conf files. Note that if the host in question is not running in.named, the local host address should not be used as a name server.

Code Example 12-25 Example resolve.conf Files

;resolv.conf file for server gull running in.named ; domain gull.com. nameserver 127.0.0.1 nameserver 223.100.101.1 nameserver 223.100.102.1

; resolv.conf file for host in zone gull not running in.named ; domain gull.com. nameserver 223.100.100.1 nameserver 223.100.101.1 nameserver 223.100.102.1

; ; resolv.conf file for a host in zone falcon.gull not running in.named ; domain falcon.gull.com nameserver 223.100.100.1 nameserver 223.100.101.1 nameserver 223.100.102.1

; resolv.conf file for a host in zone owl.gull not running in.named ; domain owl.gull.com. nameserver 223.100.100.1 nameserver 223.100.101.1 nameserver 223.100.102.1

Code Example 12-26 shows sample named.local files:

Code Example 12-26 Example named.local Files

; ; named.local for server gull ; @ IN SOA gull.com. ralph.sysad.owl.gull.com. ( 101 ;Serial 10800 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum IN NS gull.com. 1 IN PTR localhost.

; ; named.local for server falcon ; @ IN SOA falcon.gull.com. ralph.sysad.owl.gull.com.( 101 ;Serial 10800 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum IN NS falcon.gull.com. 1 IN PTR localhost.

; ; named.local for server owl ; @ IN SOA owl.gull.com. ralph.sysad.owl.gull.com. ( 101 ;Serial 10800 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum IN NS owl.gull.com. 1 IN PTR localhost.

Code Example 12-27 shows the hosts file for server gull, followed by its $INCLUDE file.

Code Example 12-27 Example hosts File for Server gull

; ; gull zone hosts file for server gull ; @ IN SOA gull.com. ralph.sysad.owl.gull.com. 101 ;Serial 10800 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum IN NS gull.com. IN NS falcon.gull.com. IN NS owl.gull.com. falcon.gull.com. IN NS falcon.gull.com. IN NS gull.com. IN NS owl.gull.com. owl.gull.com. IN NS owl.gull.com. IN NS gull.com. IN NS falcon.gull.com. gull.com. IN MX 10 gull.com. *.gull.com. IN MX 10 gull.com. ; gull.com hosts

Code Example 12-28 Example include File for Server gull

$INCLUDE /var/named/hosts/gull ; hosts in gull zone as listed in /var/named/hosts/gull gull A 223.100.100.1 A 10.1.0.56 MX 10 gull.com. falcon A 223.100.101.1 ; HINFO SPARC 10 Solaris 2.5 MX 10 gull.com. WKS 223.100.101.1 UDP syslog timed domain WKS 223.100.101.1 TCP (echo telnet discard rpc sftp uucp-path systat daytime netstat qotd nntp link chargen ftp auth time whots mtp pop rje finger smtp supdup hostnames domain nameserver) owl A 223.100.102.1 ; HINFO SPARC 5 MX 10 gull.com. WKS 223.100.102.1 UDP syslog timed domain WKS 223.100.102.1 TCP (echo telnet discard sftp uucp-path systat daytime netstat qotd nntp link chargen ftp auth time whots mtp pop rje finger smtp supdup hostnames domain nameserver) puma A 223.100.100.2 ; HINFO SPARC 5 Solaris 2.4 MX 10 gull.com. tiger A 223.100.100.3 ; HINFO SPARC 20 Solaris 2.3 MX 10 gull.com. lion A 223.100.100.4 ; HINFO SPARC 1000 Solaris 2.5 MX 10 gull.com. ; all other hosts follow, up to 223.100.100.80

Code Example 12-29 shows a hosts file for server falcon, followed by its $INCLUDE file.

Code Example 12-29 Example hosts and include File for Server Falcon

; ; falcon zone hosts file for server falcon ; @ IN SOA falcon.gull.com.ralph.sysad. owl.gull.com. 101 ;Serial 10800 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum IN NS falcon.gull.com. IN NS gull.com. IN NS owl.gull.com. ; gull.com hosts $INCLUDE /var/named/hosts/falcon ; hosts in falcon zone as listed in /var/named/hosts/falcon falcon A 223.100.101.1 ; HINFO SPARC 10 Solaris 2.5 MX 10 gull.com. machine1 CNAME falcon.gull.com machine2 A 223.100.101.2 ; HINFO SPARC 10 Solaris 2.5 MX 10 gull.com. machine3 A 223.100.101.3 ; HINFO SPARC 10 Solaris 2.5 MX 10 gull.com. machine4 A 223.100.101.4 ; HINFO SPARC 5 Solaris 2.3 WKS 223.100.101.4 UDP who route WKS 223.100.101.4 TCP (echo telnet discard sftp uucp-path systat daytime netstat ftp finger domain nameserver) MX 10 gull.com. ; all other hosts follow, up to 223.100.101.110

Code Example 12-30 is the sample file of reverse addresses for hosts in the zone gull. Note that the name of the domain is fully qualified, so that the addresses of the hosts (without the network address) is sufficient in this case:

Code Example 12-30 Example Reverse Address for Server Gull

; reverse address file for server gull, in /var/named/gull.revzone 100.100.223.in-addr.arpa.IN SOA gull.com.ralph.sysad. owl.gull.com. 101 ;Serial 10800 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum IN NS gull.com. 1 PTR gull.com. 2 PTR puma.gull.com. 3 PTR tiger.gull.com. 4 PTR lion.gull.com. ; all other hosts follow, up to 223.100.100.80

The reverse address files for servers falcon and owl should be written in a manner similar to the above.

Setting Up a Root Server for a Local Network

If you are not connecting your local network to the Internet, you must set up primary and secondary name servers in the root-level domain on the local network. This is so all domains in the network have a consistent authoritative server to which to refer; otherwise, machines may not be able to resolve queries.

Since a single machine can be the primary domain name server for more than one machine, the easiest way to create a root domain name server is to have a server be the name server for all the domains that make up its own domain name. For example, if a server is named x.sub.dom., then it should be designated the primary name server for ".", dom., and sub.dom.

Since the root name server provides an authoritative name server at the root level of the network, all top-level domains should have their name-server records (IN NS) defined in the root domain.

---

Note - The root domain server name should be the primary name server for all top-level domains in the network.

---