test

Solaris Naming Setup and Configuration Guide

Part V DNS Setup and Configuration

This part gives an overview of the Domain Name System (DNS) and describes how to setup DNS clients and servers. It has two chapters.

Chapter 12 Setting Up DNS Clients

This chapter describes how to set up Domain Name System (DNS) service on client machines.

Note -

One of the most common, and important, uses of DNS is connecting your network to the global Internet. In order to connect to the Internet, your network IP address must be registered with whomever is administering your parent domain. Who that administrator is varies according to your geographic location and type of parent domain. This manual does not describe how to register networks with domain administrators.

For more detailed information, see DNS and Bind, by Cricket Liu and Paul Albitz (O'Reilly, 1992).

Solaris DNS BIND Implementation

For your convenience, the Solaris 7 release supplies a compiled version of Berkeley Internet Name Domain (BIND) version 4.9.4, Patch-Level 1. In compiling this software, options and choices were made to meet the needs of the greatest number of sites. If this pre-compiled version of BIND does not meet your requirements, you can recompile your own version of BIND from the publicly available source code.

In compiling the BIND version supplied with the Solaris 7 release, the following choices were made:

Setting Up DNS Service

Setting up DNS service is accomplished in two basic steps:

  1. Set up DNS service on your client machines. This chapter describes how to do this.

  2. Set up your DNS servers as described in Chapter 13, Setting Up DNS Servers.

Client Set Up

Setting up DNS on a client machine involves two tasks:

If you are setting up DNS service on a host that will function as a DNS server, you also need to set up boot and data files, as described in Chapter 13, Setting Up DNS Servers.

The Resolver

DNS clients use the dynamic library routines, collectively called the resolver, to locate a remote host. The resolver queries the DNS database on a name server, which eventually returns the host name or IP address of the machine requested by the resolver. Because DNS name servers are clients of servers outside their local domains, they must also run the resolver.

The DNS name server uses several files to load its database. At the resolver level, it needs the file /etc/resolv.conf listing the addresses of the servers where it can obtain its information. The resolver reads this resolv.conf file to find the name of the local domain and the location of name servers. It sets the local domain name and instructs the resolver routines to query the listed name servers for information. Normally, each DNS client system on your network has a resolv.conf file in its /etc directory. (If a client does not have a resolv.conf file, it defaults to using a server at IP address 127.0.0.1.)

Whenever the resolver has to find the IP address of a host (or the host name corresponding to an address), the resolver builds a query package and sends it to the name servers listed in /etc/resolv.conf. The servers either answer the query locally or contact other servers known to them, ultimately returning the answer to the resolver.

Creating the resolv.conf File

A simple example resolv.conf file for a client (non-server) machine in the doc.com domain is shown in Example 12-1:

Example 12-1 Sample resolv.conf File


; Sample resolv.conf file for the machine polaris
domain doc.com
; try local name server
nameserver 127.0.0.1
; if local name server down, try these servers
nameserver 123.45.6.1
nameserver 111.22.3.5
; sort the addresses returned by gethostbyname(3c)
sortlist
130.155.160.0/255.255.240.0
130.155.0.0

The first line of the /etc/resolv.conf file lists the domain name in the form: 


domain domainname

Where domainname is the name registered with the Internet governing bodies (as of this writing, the InterNIC).

Note -

No spaces or tabs are permitted at the end of the domain name. Make sure that you enter a hard carriage return immediately after the last character of the domain name.

The second line identifies the loopback name server in the form:


nameserver 127.0.0.1

Succeeding lines list the IP addresses of up to three DNS master, secondary, or cache-only name servers that the resolver should consult to resolve queries. (Do not list more than three primary or secondary servers.) Name server entries have the form:


nameserver IP_address

Where IP_address is the IP address of a primary or secondary DNS name server. The resolver queries these name servers in the order they are listed until it obtains the information it needs.

The fifth line of the /etc/resolv.conf file lists the address sortlist in the form: 


sortlist
addresslist

Where addresslist specifies the sort order of the addresses returned by gethostbyname(3c). In our example, gethostbyname returns the netmask pair 130.155.160.0/255.255.240.0 ahead of the IP address 130.155.0.0.

Modifying the /etc/nsswitch.conf File

How you enable a machine to use DNS depends on your underlying enterprise-level name service:

For additional information on the nsswitch.conf file, see Solaris Naming Administration Guide.

Chapter 13 Setting Up DNS Servers

This chapter describes how to set up a Domain Name System (DNS) name server.

Setting Up DNS Servers

How to Set Up DNS Servers

To set up a DNS server:

  1. Set the server up as a DNS client (this includes setting up the server's resolv.conf file). See Chapter 12, Setting Up DNS Clients.

  2. Set up the boot file. See "The named.conf File".

  3. Set up the data files See "Setting Up the Data Files". You need to set up four data files:

    1. The named.ca file. See "Setting Up the named.ca File".

    2. The hosts file. See "Setting Up the hosts File".

    3. The hosts.rev file. See "Setting Up the hosts.rev File".

    4. The named.local file. See "Setting Up the named.local File".

  4. Initialize the server. See "Initializing the Server".

  5. Test the server. See "Testing Your Installation".

    Note -

    The most common use of DNS is to connect your network to the global Internet. In order to connect to the Internet, your network IP address must be registered with whomever is administering your parent domain. Who that administrator is varies according to your geographic location and type of parent domain. This manual does not describe how to register networks with domain administrators.

Server Configuration and Data File Names

To function correctly, the in.named daemon requires a configuration file and four data files.

Caution - Caution -

The IP addresses and network numbers used in examples and code samples in this manual are for illustration purposes only. Do not use them as shown because they may have been assigned to an actual network or host.

Configuration File

The master server configuration file is /etc/named.conf. (See "The named.conf File".) The configuration file contains a list of domain names and the file names containing host information. (See Solaris Naming Administration Guide for additional information on the named.conf file.)

Names of DNS Data Files

So long as you are internally consistent, you can name the zone data files anything you want. This flexibility may 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 use generic names that identify a file's main purpose, and specific example names for that file in code 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 in code samples.

For reference purposes, Table 13-1 compares BIND file names from these three sources:

Table 13-1 File Name Examples

Solaris Names 

O'Reilly Names or other names 

U.C. Berkeley Names 

Content and Purpose of File 

/etc/named.conf, same file name for all three sources

BIND 8.1 adds a new named.conf file to replace the earlier named.boot file. This configuration file adds security, startup options, logging. It specifies the type of server it is running on and selectively applies options on a per-zone or per-server basis, rather than all zones or servers. It contains a list of domain names and the names of the data files.

/etc/resolv.conf, same file name for all three sources

This file resides on every DNS client (including DNS servers) and designates the servers that the client queries for DNS information. 

named.ca

db.cache

db.root

root.cache

This file establishes the names of root servers and lists their addresses. 

Generic: hosts Examples: db.doc, db.sales

Generic: db.domain Examples: db.movie, db.fx

Generic: hosts

Example: ucbhosts

This file contains all the data about the machines in the local zone that the server serves. 

Generic: hosts.rev Examples: doc.rev

Generic:db.ADDR Examples db.192.249.249 db.192.249.253

hosts.rev

This file specifies a zone in the in-addr.arpa. domain, a special domain that allows reverse (address-to-name) mapping.

named.local

Generic: db.cache Example: db.127.0.0

named.local

This file specifies the address for the local loopback interface, or local host. 

$INCLUDE files, same convention for all three sources

Any file identified by an $INCLUDE() statement in a data file.

Data Files

The four required data files are:

$INCLUDE Files

An include file is any file named in a $INCLUDE() statement in a DNS data file. $INCLUDE files can be used to separate different types of data into multiple files for your convenience. (See Solaris Naming Administration Guide for additional details.)

Domain Names

A domain name is the name assigned to a group of systems on a local network that share DNS administrative files. A domain name is required for the network information service database to work properly.

Default Domain Name

DNS obtains your default domain name from your resolv.conf file.

Trailing Dots in Domain Names

When working with DNS-related files, follow these rules regarding the trailing dot in domain names:

resolv.conf File

The following discussion describes how to set up the resolv.conf file.

How to Set Up the resolv.conf File

A simple example resolv.conf file for a server in the doc.com domain is shown below:

Example 13-1 Sample resolv.conf File for DNS Server


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

The first line of the /etc/resolv.conf file lists the domain name in the form:


domain domainname

Where domainname is the name registered with the Internet governing bodies (as of this writing, the InterNIC).

Note -

No spaces or tabs are permitted at the end of the domain name. Make sure that you enter a hard carriage return immediately after the last character of the domain name.

The second line identifies the server itself in the form:


nameserver 0.0.0.0

Succeeding lines list the IP addresses of one or two secondary or cache-only name servers that the resolver should consult to resolve queries. Name server entries have the form:


nameserver IP_address

Where IP_address is the IP address of a secondary or cache only DNS name server. The resolver queries these name servers in the order they are listed until it obtains the information it needs.

The named.conf File

BIND 8.1 adds a new configuration file, /etc/named.conf, that replaces the /etc/named.boot file. The /etc/named.conf file establishes the server as a primary, secondary, 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 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.

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.

Table 13-2 named.conf Statements
acl

Defines a named IP address match list used for access control. The address match list designates one or more IP addresses (dotted-decimal notation) or IP prefixes (dotted-decimal notation followed with a slash and the number of bits in the netmask). The named IP address match list must be defined by an acl statement before it can be used elsewhere; no forward references allowed.
include

Inserts an include file at the point where the include statement is encountered. Use include to break up the configuration into more easily managed chunks.
key

Specifies a key ID used for authentication and authorization on a particular name server. See the server statement.
logging

Specifies what information the server logs and the destination of log messages. 
options

Controls global server configuration options and sets default values for other statements. 
server

Sets designated configuration options associated with a remote name server. Selectively applies options on a per-server basis, rather than to all servers. 
zone

Defines a zone. Selectively applies options on a per-zone basis, rather than to all zones. 

Example 13-2 Example Master Configuration File for a Primary 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 primary 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;
         };
};

Migration from BIND 4.9.x to BIND 8.1

Become super user and run the Korn shell script, /usr/sbin/named-bootconf, to convert a BIND 4.9.x named.boot file to a BIND 8.1 named.conf file. See named-bootconf(1M).

Note -

The named.boot and named.conf files cannot coexist in the same server.

Specifying Server Function

DNS servers perform one or more functions:

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:

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

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.

Note -

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:

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.

See Solaris Naming Administration Guide for a description of resource records, their formats, the fields they contain, special characters, and control entries.

Resource Record Types

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

Table 13-3 Commonly Used Resource Record Types

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 

MX 

mail exchanger 

See Solaris Naming Administration Guide for detailed descriptions of these Resource Record types.

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

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

Example 13-4 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 ourprimary and oursecondary. The named.ca files on all of your DNS servers would then look like this:

Example 13-5 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   ourprimary.private.
1.1.192.in-addr.arpa             IN    NS   ourprimary.private.

ourprivate.private.              IN    A    192.1.1.1
;
private.                         IN    NS   oursecondary.private.
1.1.192.in-addr.arpa             IN    NS   ourseconary.private.
oursecondary.private.            IN    A    192.1.1.2

See "Setting Up a Non-Internet Root Master" for a more complete discussion of setting up a domain that is not connected to the Internet.

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 Subdomains--Same Zone").

Note -

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 (primary and secondary) servers of the other zones, as described in "Setting Up Subdomains--Different Zones".

Example 13-6 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  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      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:

(See Solaris Naming Administration Guide for detailed descriptions of these resource record types.)

Setting Up the hosts.rev File

The hosts.rev file sets up inverse mapping.

Note -

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 13-7 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 these elements:

(See Solaris Naming Administration Guide for detailed descriptions of these resource record types.)

Setting Up the named.local File

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

Example 13-8 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:

See Solaris Naming Administration Guide for detailed descriptions of these resource record types.

Initializing the Server

To initialize a server:

  1. Install the named.boot boot file and the required data files, as described in the previous sections.

  2. Run in.named.


    # /usr/sbin/in.named

    Instead of running in.named from the command line, you can reboot.

Testing Your Installation

After your boot and data files are set up and in.named running, test your installation as follows:

  1. Check your syslog file for error messages.

    See Solaris Naming Administration Guide for common DNS error messages and troubleshooting information.

  2. Look up a host name in the local domain with nslookup. 


    dnsmaster% nslookup altair
 Server:  dnsmaster.doc.com
 Address: 192.146.168.5
 Name:  altair.doc.com
 Address: 192.146.168.10

    • If your lookup is successful, your name server is probably functioning correctly.

    • If you get a "Can't find," or "can't initialize address," type of message for your server, or a "Non-existent domain," type message, it may mean that your server is not correctly listed in the boot or hosts files.

    • If you get a "can't find name" or "Non-existent domain" type of message, it may mean that the host you looked up is not in the server's hosts file, or the domain is incorrectly set in resolv.conf, or there is some other server problem.

  3. Look up a remote domain name with nslookup.

    If your network is connected to the Internet, look up the name of a remote domain. (If your network is not connected to the Internet, look up the name of a subdomain in another zone, if you have one.) For example, to look up the name of the remote internic.net Internet domain, you would enter:


    dnsmaster% nslookup internic.net
Server:  dnsmaster.doc.com  
Address: 192.146.168.  
Name:  internic.net 
 Addresses: 198.41.0.9,  198.41.0.6,  198.41.0.5,  198.41.0.8

    • If you are successful, your name server is probably functioning correctly.

    • If the above command does not find the remote domain name, one possible cause is that your network's connection to the Internet is not functioning properly.

    • Another possible cause is that your named.ca file is not properly installed or set up.

    (The second time you use nslookup to find a domain, your answer will be returned as "non-authoritative." This is normal because the answer is now coming from your cache, not the remote name server.)

  4. Look up a host name in your domain from a remote domain.

    If your network is connected to the Internet, look up the name of a host in your domain from a remote domain. (If your network is not connected to the Internet, look up the name of a host in your domain from another zone, if you have one.)

    For example, to look up the name of a host in your domain, from a remote Internet domain, you would enter two arguments after the nslookup command: First the name of the host you are searching for, and second, the name of the name server you are testing: 


    remotemachine9% nslookup altair remotemaster.foo.org.
 Server:  remotemaster.foo.org
 Address: 123.231.12.22
 Name:  altair.doc.com
 Addresses: 111.22.3.4

    • If you are successful, your name server is probably functioning correctly.

    • If the above command does not find the machine you are searching for, one possible cause is that your domain is not properly registered with whomever is administering the parent domain (.com in the above example).

Setting Up Subdomains

Setting Up Subdomains--Same Zone

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

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:

The example files in Table 13-4 illustrate a network with two zones.

Setting Up a Non-Internet Root Master

If your network is connected to the Internet, your root domain server exists at the root domain Internet site; all you need to do is provide that site's Internet IP addresses in your cache file, as explained in "Internet named.ca File".

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

For example, suppose your non-Internet domain is named private and you designate the machine ourroot as your root server. The ourroot machine has an IP address of 192.1.1.10. You would then perform the following steps:

  1. Create named.ca files on your primary master servers that point to your own root server.

    For example:


    ourroot.private.  999999  A  192.1.1.10

    A named.ca file must also contain NS records for each internal domain and subdomain and A records for each server as described in "Setting Up a Non-Internet Root Master".

  2. Add a cache resource record for the root domain to the boot files of all DNS name servers on your network.

    For example:


    cache     .    named.ca

    (See "Configuration File" for more information.)

  3. Remove the root domain cache resource record from the boot file of your root server.

    In other words, delete the cache . named.ca line from ourroot's boot file.

  4. Insert a primary line for the root domain in the root server's boot file.

    For example, in ourroot's boot file you would add the line:


    primary    .  ourroot.private
    Caution - Caution -

    If you later decide to connect your network to the Internet, you must replace all the named.ca files on all of your servers with the current Internet files and replace the primary . rootserver line with a cache . named.ca line in the former root server's boot file.

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.

Caution - Caution -

The IP addresses and network numbers used in examples and code samples in this manual are for illustration purposes only. Do not use them as shown because they may have been assigned to an actual network or host.

This practical example assumes:

Table 13-4 Example Network Domain and Zone Configuration

Name and Zone 

Number 

doc.com

123.45.6

sales.doc.com

111.22.3

Table 13-5 Example Network DNS Servers

Zone 

Host Name 

Function 

Address 

 CNAME

doc.com

sirius

primary for doc.com

123.45.6.1

dnsmaster

doc.com

deneb

secondary for doc.com

111.22.3.5

dnssecond

sales.doc.com

altair

primary for sales.doc.com

111.22.3.4

dnssales

sales.doc.com

altair

secondary for sales.doc.com

123.45.6.1

dnsmaster

Example Boot Files

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

Example 13-9 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 primary files
cache         .                         named.ca
primary       doc.com                   db.doc
primary       0.0.127.in-addr.arpa      named.local
primary       6.45.123.in-addr.arpa     doc.rev
;This system is also the secondary for the sales.doc.com domain
secondary     sales.doc.com             111.22.3.4   db.sales
secondary     3.22.111.in-addr.arpa     111.22.3.4   sales.rev
Example 13-10 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 primary files
cache      .                        named.ca
primary    sales.doc.com            db.sales
primary    0.0.127.in-addr.arpa     db.127.0.0
primary    3.22.111.in-addr.arpa    db.192.168.8
Example 13-11 Example Boot File for dnssecond Server


; named.boot file on the dnsecond (deneb)
directory /var/named
cache           .               named.ca
secondary       doc.com         123.45.6.1 doc.com
secondary       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 13-12 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 13-13 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 13-14 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 primary servers on the two networks. Both servers have the same file.

Example 13-15 Example named.local File for Both Primary 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 primary servers on the two networks.

Example 13-16 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.   IN  A   111.22.3.4
; aliases
dnsmastr                IN  CNAME    sirius.doc.com.
dnssecond.doc.com       IN  CNAME   deneb.doc.com
Example 13-17 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 primary servers on the two networks:

Example 13-18 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 13-19 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 primary servers on the two networks. Both servers use identical named.ca files.

Example 13-20 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