Creating Boot and Data Files

In addition to the daemon in.named, DNS on a name server consists of a boot file and local data files. The default location of the boot file is /etc/named.boot. Common names for the local data files are named.ca,

named.local, hosts, and hosts.rev. In the descriptions of these files that follow, these names are used. However, you can name these files whatever you wish. In fact, it is suggested that you use names other than the ones used in this guide, to avoid confusion with files with similar names.

named.boot

The boot file named.boot establishes the server as a primary, a secondary, or a 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.

named.ca

named.ca establishes the names of root servers and lists their addresses. If you are connected to the Internet, named.ca lists the Internet name servers; otherwise, it lists the root domain name servers for your local network.

in.named 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.

To avoid confusion with the caching process, which has very little to do with this, you may want to call your file something like named.root or boot.root.

hosts

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. In Code Example 10-1 on page 135, the file is called puhosts.

hosts.rev

The hosts.rev file specifies a zone in the IN-ADDR.ARPA domain (the special domain that allows inverse mapping). The name of this file is specified in the boot file. In the illustration, the file is called puhosts.rev.

named.local

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. As with all other files, it can be called something other than the name used in this guide.

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 and secondary master servers 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.

The following is a sample boot file for a primary server:

Code Example 10-1 Sample Master Boot File

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

The entries in the file are explained below.

directory The following 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. It 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 it must be full path names.

cache 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).

primary To set up a primary server, you need to create a file that contains all the authoritative data for the zone. Then you 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 Podunk.Edu. puhosts

The first field designates the server as primary for the zone stated in the second field. The third field is the name of the file from which authoritative data is read.

The lines:

primary 32.128.in-addr.arpa puhosts.rev primary 0.0.127.in-addr.arp named.local

indicate that the server is also a primary server for 32.128.in-addr.arpa (that is, the reverse address domain for Podunk.Edu) and 0.0.127.in-addr.arpa (that is, the local host loopback), and data for them is to be found, respectively, in the files puhosts.rev and named.local.

The following is a sample boot file for a secondary server in the same domain as the above primary server:

; ; Sample named.boot file for Secondary Master Name Server ; ; type domain source file or host ; directory /var/named cache . named.ca secondary Podunk.Edu. 128.32.0.4 128.32.0.10 128.32.136.22 puhosts.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 Podunk.Edu.128.32.0.4 128.32.0.10 128.32.136.22 puhosts.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, and that it is to get its data from the listed servers (usually the primary server followed by one or more secondary ones); attempts 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 server is started, data are loaded from the backup file, if it exists, and then one of the servers is consulted to check whether the data is still up to date.

This ability to specify multiple secondary 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; it is the mixture of entries in the boot file that determines it.

---

The interpretation of the other "secondary line" is similar to the above. Note also that although this is a secondary server for the domain Podunk.Edu and 32.128.in-addr.arpa, this is a primary server for 0.0.127.in-addr.arpa. (the local host).

The following is a sample boot file for a 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 above, 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. 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. Following this section is a discussion of the Standard Resource Record Format, including an explanation of each Resource Record relevant to the DNS data files.

The hosts file contains all the data about all the machines in your zone, including server names, 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, HINFO, CNAME, WKS, MX, MB, MR, MG. The file also include the SOA record, which indicates the start of a zone and includes the name of the host on which the hosts data file resides. The example on the following page shows a sample hosts file.

; sample hosts file @ IN SOA ourfox.Sample.Edu. kjd.monet.Sample.Edu. ( 1.1 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS ourarpa.Sample.Edu. IN NS ourfox.Sample.Edu. ourarpa IN A 128.32.0.4 IN A 10.0.0.78 IN HINFO 3B2 UNIX arpa IN CNAME ourarpa ernie IN A t128.32.0.6 IN HINFO 3B2 UNIX ourernie IN CNAME ernie monet IN A 128.32.7 IN A 128.32.130.6 IN HINFO Sun-4/110 UNIX ourmonet IN CNAME monet ourfox IN A 10.2.0.78 IN A 128.32.0.10 IN HINFO Sun-4/110 UNIX 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 ) fox IN CNAME ourfox toybox IN A 128.32.131.119 IN HINFO 3B2 UNIX toybox IN MX 0 monet.Sample.Edu

The named.local file sets up the local loopback interface for your name server. It needs to 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 by the PTR record. The file also needs to 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. Here is a sample named.local file:

; sample named.local file @ IN SOA ourhost.Podunk.Edu. kjd.monet.Podunk.Edu. ( 1 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS ourhost.Podunk.Edu. 1 IN PTR localhost.

hosts.rev is the file that sets up inverse mapping. It needs to 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 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.

Here is a sample hosts.rev file:

; sample hosts.rev file @ IN SOA ourhost.Podunk.Edu. kjd.monet.Podunk.Edu. ( 1.1 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS ourarpa.Podunk.Edu. IN NS ourhost.Podunk.Edu. 4.0 IN PTR ourarpa.Podunk.Edu. 6.0 IN PTR ernie.Podunk.Edu. 7.0 IN PTR monet.Podunk.Edu. 10.0 IN PTR ourhost.Podunk.Edu. 6.130 IN PTR monet.Podunk.Edu.

The named.ca file contains the names and addresses of the root servers. Server names are indicated in the record NS and addresses in the record A. You need to add an NS record and an A record for each root server you want to include in the file.

The following is a 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

Standard Resource Record Format

In the Standard Resource Record Format, each line of a data file is a record called a Resource Record (RR), containing 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 braces), and the contents of the last vary according to the Record Type field.

name 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 one, in which case the current domain is appended to it.

ttl 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 resource record discussed below.

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, 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, and 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, and 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.

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

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

RR data The contents of the 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, and you are advised to be consistent in your use of lower and upper case.

Special Characters

The following characters have special meanings:

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

( )Use parentheses to group data that crosses a line. In effect, line terminations are not recognized within parentheses.

;Semicolon starts a comment; the remainder of the line is ignored.

*An asterisk signifies wildcarding.

Most resource records have the current origin appended to names if they are not terminated by a "." This is useful for appending the current domain name to the data, such as machine names, but may cause problems where you do not want this to happen. A good rule of thumb is to 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 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, for example:

$INCLUDE /etc/named/data/mailboxes

The line is interpreted as a request to load the file /etc/named/data/mailboxes 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

Some of the most commonly used types of RR's are listed in Table 10-1.

Table 10-1

Type	Description
SOA	Start of Authority
NS	Name Server
A	Internet Address
CNAME	Canonical Name (nickname)
HINFO	Host Information
WKS	Well Known Services
PTR	Pointer
MX	Mail Exchanger

Code Example 10-2 on page 147 shows an example of a hosts file. It is presented here for illustration purposes only. Explanations of each field follow the code example.

Code Example 10-2 Sample hosts File

; sample hosts file @ IN SOA ourfox.Sample.Edu. kjd.monet.Sample.Edu. ( 1.1 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS ourarpa.Sample.Edu. IN NS ourfox.Sample.Edu. IN A 128.32.0.4 ourarpa IN A 10.0.0.78 IN HINFO 3B2 UNIX arpa IN CNAME ourarpa ernie IN A 128.32.0.6 IN HINFO 3B2 UNIX ourernie IN CNAME ernie monet IN A 128.32.7 IN A 128.32.130.6 IN HINFO Sun-4/110 UNIX ourmonet IN CNAME monet ourfox IN A 10.2.0.78 IN A 128.32.0.10 IN HINFO Sun-4/110 UNIX 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 nntplink chargen ftp auth time whois mtp pop rje finger smtp supdup hostnames domain nameserver ) fox IN CNAME ourfox toybox IN A 128.32.131.119 IN HINFO 3B2 UNIX toybox IN MX 0 monet.Sample.Edu

SOA - Start of Authority

The following is the format of a Start of Authority resource record:

name {ttl} {class} SOA origin person in charge ( serial refresh retry expire minimum )

The Start of Authority (SOA) record designates the start of a zone. The zone ends at the next SOA record.

name
This field indicates the name of the zone. In the Code Example 10-2 on
page 147, @ indicates the current zone or origin.

IN

This field is the address 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.

Person_in_charge This field is the mailing address for the person responsible for the name server.

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.

Note that the name server cannot handle numbers over 9999 after the decimal point.

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.

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. The following is a sample SOA resource record:

;name {ttl} class SOA origin person in charge @ IN SOA ourfox.Sample.Edu.kjd.monet.Sample.Edu.( 1.1 ;Serial 10800 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum

NS - Name Server

The following is the format of an NS resource record:

{name} {ttl} class NS Name-server name

The Name Server record (NS) 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. The following is a sample NS resource record:

;{name} {ttl} class NS Name-server name IN NS ourarpa.Sample.Edu.

A - Address

The following is the format of an A resource record:

{name} {ttl} class A address

The Address record (A) lists the address for a given machine. The name field is the machine name, and the address is the IP address. One A record should exist for each address of the machine (in other words, gateways should be listed twice, once for each address).

;{name} {ttl} class A address ourarpa IN A 128.32.0.4 IN A 10.0.0.78

HINFO - Host Information

The following is the format of a HINFO resource record:

{name} {ttl} class HINFO Hardware OS

The Host Information resource record (HINFO) 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. The following is a sample HINFO resource record:

;{name} {ttl} class HINFO Hardware OS IN HINFO Sun-3/280 UNIX

WKS - Well Known Services

The following is the format of a WKS resource record:

{name} {ttl} class WKS address protocollist of services

The Well Known Services record (WKS) 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. The following is an example of a WKS resource record:

;{name} {ttl} class WKS address protocollist 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)

CNAME - Canonical Name

The format of a CNAME resource record is:

nickname {ttl} class CNAME Canonical_name

The Canonical Name resource record (CNAME) 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. The following is a sample CNAME resource record:

;nickname {ttl} class CNAME Canonical_name ourmonet IN CNAME monet

PTR - Domain Name Pointer

The following is the format for a PTR resource record:

special name {ttl} class PTR_real_name

A Pointer record (PTR) allows special names to point to some other location in the domain. 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 below set up reverse pointers for the special IN-ADDR.ARPA domain.

;special name {ttl} class PTR real name 7.0 IN PTR monet.Podunk.Edu. 2.2.18.128.in-addr.arpa IN PTR blah.junk.COM.

MX - Mail Exchanger

The following is the format for an MX resource record:

name {ttl} class MX preference_ value mailer_exchanger

The Mail Exchanger (MX) 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 10-3 on

page 153, 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, they 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 10-3, 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 10-3 MX 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.

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 up, it 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 up 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 10-2

name	number
junk	223.100.100
widget	223.100.101
zap	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 the Domain Name Service 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 10-3 junk

hostname	function	address
junk	primary	223.100.100.1
widget	secondary	223.100.101.1
zap	secondary	223.100.102.1
	hosts	223.100.100.2-80

Table 10-4 widget

hostname	function	address
widget	primary	223.100.101.1
junk	secondary	223.100.100.1
zap	secondary	223.100.102.1
	hosts	223.100.101.2-110

Table 10-5 zap

hostname	function	address
zap	primary	223.100.102.1
junk	secondary	223.100.100.1
widget	secondary	223.100.101.1
	hosts	223.100.102.2-156

The following are the boot files for the three servers in the network:

; ; Boot file for server junk directory /var/named cache . named.root primary junk.COM junk.zone primary 100.100.223.in-addr.arpa junk.revzone primary 0.0.127.in-addr.arpa named.local secondary widget.junk.COM 223.100.101.1 223.100.102.1 widget.zone secondary zap.junk.COM 223.100.101.1 223.100.102.1 zap.zone secondary 101.100.223.in-addr.arpa 223.100.101.1 widget.rev secondary 102.100.223.in-addr.arpa 223.100.102.1 zap.rev

; ; Boot file for server widget directory /var/named cache . named.root primary widget.junk.COM widget.zone primary 101.100.223.in-addr.arpa widget.revzone primary 0.0.127.in-addr.arpa named.local secondary junk.COM 223.100.100.1 223.100.102.1 junk.zone secondary zap.junk.COM 223.100.100.1 223.100.102.1 zap.zone secondary 100.100.223.in-addr.arpa 223.100.100.1 junk.rev secondary 102.100.223.in-addr.arpa 223.100.102.1 zap.rev

; ; Boot file for server zap directory /var/named cache . named.root primary zap.junk.COM zap.zone primary 102.100.223.in-addr.arpa zap.revzone primary 0.0.127.in-addr.arpa named.local secondary junk.COM 223.100.100.1 223.100.102.1 junk.zone secondary widget.junk.COM 223.100.100.1 223.100.101.1 widget.zone secondary 100.100.223.in-addr.arpa 223.100.100.1 junk.rev secondary 101.100.223.in-addr.arpa 223.100.101.1 widget.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 nameserver.

; ; resolv.conf file for server junk ; domain junk.COM nameserver 127.0.0.1 nameserver 223.100.101.1 nameserver 223.100.102.1

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

; ; resolv.conf file for a host in zone widget.junk not running named ; domain widget.junk.COM nameserver 223.100.100.1 nameserver 223.100.101.1 nameserver 223.100.102.1

; ; resolv.conf file for a host in zone zap.junk not running named ; domain zap.junk.COM nameserver 223.100.100.1 nameserver 223.100.101.1 nameserver 223.100.102.1

The following are sample named.local files:

; ; named.local for server junk ; @ IN SOA junk.COM. ralph.sysad.zap.junk.COM. ( 1.1 ;Serial 10800 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum IN NS junk.COM. 1 IN PTR localhost.

; ; named.local for server widget ; @ IN SOA widget.junk.COM. ralph.sysad.zap.junk.COM.( 1.1 ;Serial 10800 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum IN NS widget.junk.COM. 1 IN PTR localhost.

; ; named.local for server zap ; @ IN SOA zap.junk.COM. ralph.sysad.zap.junk.COM. ( 1.1 ;Serial 10800 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum IN NS zap.junk.COM. 1 IN PTR localhost.

The hosts file for server junk, followed by its $INCLUDE file, appears in the following code sample:

Code Example 10-4 The hosts File for Sample Server junk

; ; junk zone hosts file for server junk ; @ IN SOA junk.COM.ralph.sysad.zap.junk.COM. ( 1.1 ;Serial 10800 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum IN NS junk.COM. IN NS widget.junk.COM. IN NS zap.junk.COM. widget.junk.COM. IN NS widget.junk.COM. IN NS junk.COM. IN NS zap.junk.COM. zap.junk.COM. IN NS zap.junk.COM. IN NS junk.COM. IN NS widget.junk.COM. junk.COM. IN MX 10 junk.COM. *.junk.COM. IN MX 10 junk.COM. ; junk.COM hosts $INCLUDE /var/named/hosts/junk ; hosts in junk zone as listed in /var/named/hosts/junk junk A 223.100.100.1 A 10.1.0.56 MX 10 junk.COM. widget A 223.100.101.1 HINFO "Sun 3/180" Unix MX 10 junk.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)

Code Example 10-5 The hosts File for Sample Server junk (Continued)

zap A 223.100.102.1 HINFO Sun-4/110Unix MX 10 junk.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) lazy A 223.100.100.2 HINFO "Sun 3/50"Unix MX 10 junk.COM. crazy A 223.100.100.3 HINFO 3B2 Unix MX 10 junk.COM. hazy A 223.100.100.4 HINFO 3B2 Unix MX 10 junk.COM. ; all other hosts follow, up to 223.100.100.80

The following is the hosts file for server widget, followed by its $INCLUDE file:

; ; widget zone hosts file for server widget ; @ IN SOA widget.junk.COM. ralph.sysad.zap.junk.COM. ( 1.1 ;Serial 10800 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum IN NS widget.junk.COM. IN NS junk.COM. IN NS zap.junk.COM. ; junk.COM hosts $INCLUDE /var/named/hosts/widget

; hosts in widget zone as listed in /var/named/hosts/widget widget A 223.100.101.1 HINFO "Sun 3/180" Unix MX 10 junk.COM. whatsit CNAME widget.junk.COM smelly A 223.100.101.2 HINFO 3B2 Unix MX 10 junk.COM. stinky A 223.100.101.3 HINFO 3B2 Unix MX 10 junk.COM. dinky A 223.100.101.4 HINFO "Sun 3/160" Unix 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 junk.COM. ; all other hosts follow, up to 223.100.101.110

The following is the sample file of reverse addresses for hosts in the zone junk. 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:

; reverse address file for server junk, in /var/named/junk.revzone 100.100.223.in-addr.arpa.IN SOA junk.COM.ralph.sysad.zap.junk.COM. ( 1.1 ;Serial 10800 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum IN NS junk.COM. 1 PTR junk.COM. 2 PTR lazy.junk.COM. 3 PTR crazy.junk.COM. 4 PTR hazy.junk.COM. ; all other hosts follow, up to 223.100.100.80

The reverse address files for servers widget and zap 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 - It is strongly recommended that the root domain server name be the primary name server for all top-level domains in the network.

---