Specifying Server Function

DNS servers perform one or more functions:

• Zone primary master server. Each zone has one server that is designated as the primary master server for that zone. A zone's primary master server is the authoritative server for that zone. (See "Specifying a Primary Master Server".)

• Zone secondary master server. A zone can have one or more secondary master servers. Secondary master servers obtain their DNS from the zone's primary master server. You do not modify data files on a secondary server; you modify the data files on the zone's primary server and the secondary servers update their files from the primary. (See "Specifying a Secondary Master Server".)

• Caching-Only Server. All servers are caching servers in the sense that they all maintain a cache of DNS data. A caching-only server is a server that is not a master server for any zone other than the in-addr.arpa. domain. (See "Specifying a Cache-Only Server".)

• Root Domain servers. If your network is connected to the Internet, your root domain servers are out on the Internet itself and all you have to do is provide their Internet IP addresses in the named.ca file, as explained in "Setting Up the named.ca File". If your network is not connected to the Internet, you have to set up your own root domain server, as explained in "Setting Up a Non-Internet Root Master".

These various server functions can be performed by the same machine. For example, a machine can be a primary master server for one zone and a secondary master server for another zone. When this manual refers to a primary, secondary, or caching-only server, it is not referring to a particular machine, but the role that machine plays for a given zone.

Refer to Solaris Naming Administration Guide for additional information on these different server functions.

Specifying a Primary Master Server

To specify a server as the primary server for a given zone, you create three primary records in that server's named.boot file:

1. Create the primary record for the zone.

   This record designates the server as a primary server for the zone and tells the server where to find the authoritative hosts file. A "primary" record has three fields:

   • The first field designates the server as "primary."

   • The second field identifies the zone it serves.

   • The third field identifies the hosts file.

   For example, the following line in a boot file specifies that the server is the primary server for the doc.com zone, using authoritative data from the file db.doc:

   primary doc.com db.doc

2. Create a primary record for the zone's reverse map.

   This record designates the server as a primary server for the zone's reverse address map (that is, the reverse address domain for doc.com), and tells the server where to find the authoritative hosts file. This record has three fields; the first field designates the server as "primary," the second field identifies the zone, and the third field identifies the hosts.rev file.

   The reverse address domain for a zone contains the zone's IP address in reverse order followed by in-addr.arpa. For example, suppose that the doc.com zone's IP address is 123.45.6. In that case, the reverse address domain would be 6.45.123.in-addr.arpa.

   Thus, the following line in a boot file specifies that the server is the primary server for the reverse address domain of the doc.com zone, using authoritative data from the file doc.rev:

   primary 6.45.123 . in-addr.arpa doc.rev

3. Create a primary record for the reverse address of the local loopback interface or host.

   This record designates the server as a primary server for the loopback host, and tells the server where to find the authoritative hosts file. This record has three fields, the first field designates the server as "primary," the second field identifies the loopback host reverse address, and the third field identifies the hosts file.

   ---

   Note -

   Loopback hosts are always identified as 0.0.127.in-addr.arpa.

   ---

   Thus, the following line in a boot file specifies that the server is the primary server for the reverse address domain of the loopback host using authoritative data from the file named.local:

   primary 0.0.127.in-addr.arpa named.local

Specifying a Secondary Master Server

To specify that a server is to be the secondary server for a given zone, you create "secondary" records in that server's named.boot file. Separate records can designate the server as a secondary server for the zone, the zone's reverse address domain, and the loopback host.

A "secondary" record has three required fields:

• The first field designates the server as "secondary."

• The second field identifies the zone it serves.

• The third field identifies the IP address of the primary server for the zone from which the secondary server obtains its authoritative data.

A "secondary" record can have one or more optional fields after the required fields. The optional fields are:

• Secondary servers. After the IP address of the primary server, you can add IP addresses of other secondary servers. These provide additional sources from which the secondary server can obtain data. Adding IP addresses of secondary servers may under some circumstances reduce performance, unless those IP addresses are additional network addresses of a multihome primary server.

• Backup file. After the IP address of the primary (and optional secondary) server(s), you can add the name of a backup hosts file. If a backup file name is present, the secondary server loads its data from that file, then checks with the primary (and optional secondary) servers to make sure that the data in the backup file is up to date. If the backup file is not up to date, it is brought up to date, based on the information received from the primary server.

For example, the following lines in a boot file specify that the server is the secondary server for the doc.com zone and its reverse address domain; that it obtains its authoritative data from the primary server with an IP address of 129.146.168.119, that it uses the server 192.146.168.38 as a secondary source of zone data, and initially loads its data from the file doc.com.bakup:

 
secondary   doc.com   129.146.168.119  192.146.168.38  doc.com.bakup
secondary   4.0.32.128.in-addr.arpa       129.146.168.119 

In the context of the various example files presented in this chapter, the sample boot file lines above correspond to the boot file of the dnssecondary server, which is an alias for the sirius machine whose IP address is 192.146.168.38.

A server can 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 server for a given zone

Specifying a Cache-Only Server

A cache-only server does not maintain any authoritative data; it handles queries and asks the hosts listed in the in.named file for the information needed. In other words, a cache-only server handles the same kind of queries that authoritative name servers perform but it does not maintain any authoritative data itself.

Example 13-3 is a sample boot file for a caching-only server.

Example 13-3 Sample Master Boot File for Caching-only Server

;
; Sample named.boot file for caching-only name server
;
; type                  domain                 source file or host
;
directory /var/named
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 cache-only server. What denotes a cache-only server is the absence of any secondary or primary authority lines in the boot file, except as noted below.

A cache-only server requires:

• A directory line in the boot file

• A primary 0.0.127.in-addr.arpa line in the boot file

• A cache . named.ca line in the boot file