Part II DNS Setup and Administration

This part describes the setup, configuration, administration and troubleshooting of DNS naming service in the Solaris operating environment.

Chapter 3 Domain Name System (Overview)

This chapter describes the structure and provides an overview of the Domain Name System (DNS).

One of the most common and important uses of DNS is connecting your network to the global Internet. To connect to the Internet, your network IP address must be registered with whomever is administering your parent domain.

This chapter covers the following topics.

• DNS Basics

• Server Configuration and Data File Names

• Domain Names

• The resolv.conf File

• The named.conf File

• Zones

DNS Basics

The Domain Name System (DNS) is an application–layer protocol that is part of the standard TCP/IP protocol suite. This protocol implements the DNS naming service, which is the naming service used on the Internet.

This section introduces the basic DNS concepts. It assumes that you have some familiarity with network administration, particularly TCP/IP, and some exposure to other naming services, such as NIS+ and NIS.

Refer to Chapter 4, Administering DNS (Tasks) for information regarding initial setup and configuration of DNS.

DNS, NIS+, NIS, and FNS provide similar functionality and sometimes use the same terms to define different entities. Thus, this chapter takes care to define terms like domain and name server according to their DNS functionality, a very different functionality than NIS+ and NIS domains and servers.

Name-to-Address Resolution

Though it supports the complex, worldwide hierarchy of computers on the Internet, the basic function of DNS is actually very simple: providing name-to-address resolution for TCP/IP-based networks. Name-to-address resolution, also referred to as mapping, is the process of finding the IP address of a computer in a database by using its host name as an index.

Name-to-address mapping occurs when a program running on your local machine needs to contact a remote computer. The program most likely will know the host name of the remote computer but might not know how to locate it, particularly if the remote machine is in another company, miles from your site. To get the remote machine's address, the program requests assistance from the DNS software running on your local machine, which is considered a DNS client.

Your machine sends a request to a DNS name server, which maintains the distributed DNS database. The files in the DNS database bear little resemblance to the NIS+ host or ipnodes Table or even the local /etc/hosts or /etc/inet/ipnodes file, though they maintain similar information: the host names, the ipnode names, IPv4 and IPv6 addresses, and other information about a particular group of computers. The name server uses the host name your machine sent as part of its request to find or “resolve” the IP address of the remote machine. It then returns this IP address to your local machine if the host name is in its DNS database.

The following figure shows name-to-address mapping as it occurs between a DNS client and a name server, probably on the client's local network.

Figure 3–1 Name to Address Resolution

If the host name is not in that name server's DNS database, this indicates that the machine is outside of its authority, or, to use DNS terminology, outside the local administrative domain. Thus, each name server is spoken of as being “authoritative” for its local administrative domain.

Fortunately, the local name server maintains a list of host names and IP addresses of root domain name servers, to which it will forward the request from your machine. These root name servers are authoritative for huge organizational domains, as explained fully in DNS Hierarchy and the Internet. These hierarchies resemble UNIX file systems, in that they are organized into an upside down tree structure.

Each root name server maintains the host names and IP addresses of top level domain name servers for a company, a university, or other large organizations. The root name server sends your request to the top-level name servers that it knows about. If one of these servers has the IP address for the host you requested, it will return the information to your machine. If the top-level servers do not know about the host you requested, they pass the request to second-level name servers for which they maintain information. Your request is then passed on down through the vast organizational tree. Eventually, a name server that has information about your requested host in its database will return the IP address back to your machine.

The following figure shows name-to-address resolution outside the local domain.

Figure 3–2 Name to Address Resolution for a Remote Host

DNS Administrative Domains

From a DNS perspective, an administrative domain is a group of machines which are administered as a unit. Information about this domain is maintained by at least two name servers, which are “authoritative” for the domain. The DNS domain is a logical grouping of machines. The domain groupings could correspond to a physical grouping of machines, such as all machines attached to the Ethernet in a small business. Similarly, a local DNS domain could include all machines on a vast university network that belong to the computer science department or to university administration.

For example, suppose the Ajax company has two sites, one in San Francisco and one in Seattle. The Retail.Sales.Ajax.com. domain might be in Seattle and the Wholesale.Sales.Ajax.com. domain might be in San Francisco. One part of the Sales.Ajax.com. domain would be in one city, the other part in the second city.

Each administrative domain must have its own unique subdomain name. Moreover, if you want your network to participate in the Internet, the network must be part of a registered administrative domain. The section Joining the Internet has full details about domain names and domain registration.

in.named and DNS Name Servers

As mentioned previously, name servers in an administrative domain maintain the DNS database. They also run the in.named daemon, which implements DNS services. in.named is a public domain TCP/IP program and is included with the Solaris operating environment.

The in.named daemon is also called the Berkeley Internet Name Domain service, or BIND, because it was developed at the University of California at Berkeley.

There are three types of DNS name servers.:

• Master server

• Slave server

• Stub server

Each domain must have one master server and should have at least one slave server to provide backup. Implementing DNS explains primary and secondary servers in detail.

Server Configuration and Data File Names

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

Configuration File

The master server configuration file is /etc/named.conf. The configuration file contains a list of domain names and the file names containing host information. See The named.conf File for additional information on the named.conf file.

Names of DNS Data Files

If you are internally consistent, you can name the zone data files anything you want. This flexibility might 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 published by O'Reilly & Associates and both of those nomenclatures have some differences from that used in the public-domain Name Server Operations Guide for BIND.

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, this manual uses 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.

The required data files are the following.

• /var/named/named.ca See The named.ca File for additional information on the named.ca file. As long as you are internally consistent, you can name this file anything you want.

• /var/named/hosts See The hosts File for additional information on hosts files.

  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. The most common naming convention is db.domainname. Thus, the hosts file for the doc.com domain would be called db.doc.

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

• /var/named/hosts.rev See The hosts.rev File for additional information on the hosts.rev file.

  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.

• /var/named/named.local See The named.local File and for additional information on the named.local file. As long as you are internally consistent, you can name this file anything you want.

$INCLUDE Files

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

For reference purposes, the following table compares BIND file names from the above mentioned sources.

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.

• If the resolv.conf file is not available, or does not identify a default domain, and if your enterprise-level naming service is either NIS+ or NIS, the Sun implementation of DNS obtains the default domain name from those services.

• If resolv.conf is not available or does not provide a domain name and you are not running either NIS+ or NIS, you must either provide a resolv.conf file on each machine that does specify the domain or set the LOCALDOMAIN environment variable.

Trailing Dots in Domain Names

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

• Use a trailing dot in domain names in hosts, hosts.rev, named.ca, and named.local data files. For example, sales.doc.com. is correct for these files.

• Do not use a trailing dot in domain names in named.boot or resolv.conf files. For example, sales.doc.com is correct for these files.

DNS Clients and the Resolver

To be a DNS client, a machine must run the resolver. The resolver is neither a daemon nor a single program. It is a set of dynamic library routines used by applications that need to know machine names. The resolver's function is to resolve users' queries. To do that, it queries a name server, which then returns either the requested information or a referral to another server. Once the resolver is configured, a machine can request DNS service from a name server.

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.

When a machine's /etc/nsswitch.conf file specifies hosts: dns (or any other variant that includes dns in the hosts line), the resolver libraries are automatically used. If the nsswitch.conf file specifies some other naming service before dns, that naming service is consulted first for host information and only if that naming service does not find the host in question are the resolver libraries used.

For example, if the hosts line in the nsswitch.conf file specifies hosts: nisplus dns, the NIS+ naming service will first be searched for host information. If the information is not found in NIS+, then the DNS resolver is used. Since naming services such as NIS+ and NIS only contain information about hosts in their own network, the effect of a hosts:nisplus dns line in a switch file is to specify the use of NIS+ for local host information and DNS for information on remote hosts out on the Internet.

There are two kinds of DNS clients.

• Client-only

  A client-only DNS client does not run in.named. Instead, it consults the resolver. The resolver knows about a list of name servers for the domain, to which queries are then directed.

• Client-server

  A client-server uses the services provided by in.named to resolve queries forwarded to it by client-machine resolvers.

The resolv.conf File

For a detailed description of what the resolv.conf file does, see resolv.conf(4).

See Setting Up the resolv.conf File for a discussion on how to set up the resolv.conf file.

The named.conf File

BIND 8.1 added a new configuration file, /etc/named.conf, that replaces the /etc/named.boot file. The /etc/named.conf file establishes the server as a master, slave, or cache-only name server. It also specifies the zones over which the server has authority and which data files it should read to get its initial data.

The /etc/named.conf file contains statements that implement:

• Security through an access control list (ACL) that defines a collection of IP addresses that an NIS+ host can read and write

• Logging specifications

• Selectively applied options for a set of zones, rather than to all zones

The configuration file is read by in.named when the daemon is started by the server's startup script, /etc/init.d/inetsvc. The configuration file directs in.named 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 block of statements. Again, each statement in the block is terminated with a semicolon.

Example 3–1 Example Master Configuration File for a Master Server

options {
         directory "/var/named";
         datasize 2098;
         forward only;
         forwarders {
                  99.11.33.44;
         };
         recursion no;
         transfers-in 10;
         transfers-per-ns 2;
         allow-transfer {
                  127.0.1.1/24;
         };
};
 
logging {
         category queries { default_syslog; };
};
 
include "/var/named/abcZones.conf"
 
 
// here are the names of the master files
zone "cities.zn" {
         type master;
         file "db.cities.zn";
};
 
zone "0.0.127.in-addr.arpa" {
         type master;
         file "db.127.cities.zn";
};
 
zone "168.192.in-addr.arpa" {
         type master;
         file "db.cities.zn.rev";
};
 
zone "sales.doc.com" {
         type slave;
         file "slave/db.sales.doc";
         masters {
                  192.168.1.151;
         };
};
 
 
zone "168.192.in-addr.arpa" {
	         type slave;
         file "slave/db.sales.doc.rev";
         masters {
                  192.168.1.151;
         };
};

DNS Hierarchy in a Local Domain

If your company is large enough, it might support a number of domains, organized into a local namespace. The following figure shows a domain hierarchy that might be in place in a single company. The top-level, or “root” domain for the organization is ajax.com, which has three subdomains, sales.ajax.com, test.ajax.com, and manf.ajax.com.

Figure 3–3 Hierarchy of DNS Domains in a Single Organization

DNS clients request service only from the servers that support their domain. If the domain's server does not have the information the client needs, it forwards the request to its parent server, which is the server in the next higher domain in the hierarchy. If the request reaches the top-level server, the top-level server determines whether the domain is valid. If it is not valid, the server returns a “not found” type message to the client. If the domain is valid, the server routes the request down to the server that supports that domain.

DNS Hierarchy and the Internet

The domain hierarchy shown in the following figure is a “leaf” of the huge DNS namespace supported on the global Internet.

It consists of the root directory, represented as a dot (.), and two top level domain hierarchies, one organizational and one geographical. Note that the com domain introduced in this figure is one of a number of top-level organizational domains in existence on the Internet.

Figure 3–4 Hierarchy of Internet Domains

At the present time, the organizational hierarchy divides its namespace into the top-level domains listed shown in the following table. It is probable that additional top-level organizational domains will be added in the future.

The geographic hierarchy assigns each country in the world a two or three-letter identifier and provides official names for the geographic regions within each country. For example, domains in Britain are subdomains of the uk top-level domain, Japanese domains are subdomains of jp, and so on.

Joining the Internet

The Internet root domain, top-level domains (organizational and geographical) are maintained by the various Internet governing bodies. People with networks of any size can “join” the Internet by registering their domain name in either the organizational or the geographical hierarchy.

Every DNS domain must have a domain name. If your site wants to use DNS for naming service without connecting to the Internet, you can use any name your organization wants for its your domains and subdomains, if applicable. However, if your site plans wants to join the Internet, it must register its domain name with the Internet governing bodies.

To join the Internet, do the following.

• Register your DNS domain name with the an appropriate Internet governing body.

• Obtain a network IP address from that governing body.

There are two ways to accomplish this.

• You can communicate directly with the appropriate Internet governing body or their agent.

• You can contract with an Internet Service Provider (ISP) to assist you. ISPs provide a wide range of services from consulting to actually hosting your Internet presence.

Domain Names

Domain names indicate a domain's position in the overall DNS namespace, much as path names indicate a file's position in the UNIX file system. After your local domain is registered, its name is added to the name of the Internet hierarchy to which it belongs. For example, the ajax domain shown in Figure 3–5 has been registered as part of the Internet com hierarchy. Therefore, its Internet domain name becomes ajax.com.

The following figure shows the position of the ajax.com domain in the DNS namespace on the Internet.

Figure 3–5 Ajax Domain's Position in the DNS Namespace

The ajax.com subdomains now have the following names.

sales.ajax.com
test.ajax.com
 manf.ajax.com

DNS does not require domain names to be capitalized, though they can be. Here are some examples of machines and domain names.

boss.manf.ajax.com
quota.sales.ajax.com

The Internet organization regulates administration of its domains by granting each domain authority over the names of its hosts and by expecting each domain to delegate authority to the levels below it. Thus, the com domain has authority over the names of the hosts in its domain. It also authorizes the formation of the ajax.com domain and delegates authority over the names in that domain. The ajax.com domain, in turn, assigns names to the hosts in its domain and approves the formation of the sales.ajax.com, test.ajax.com, and manf.ajax.com domains.

Fully Qualified Domain Names (FQDNs)

A domain name is said to be fully-qualified when it includes the names of every DNS domain from the local domain on up to “.”, the DNS root domain. Conceptually, the fully qualified domain name indicates the path to the root, as does the absolute path name of a UNIX file. However, fully qualified domain names are read from lowest, on the left, to highest, on the right. Therefore, a fully-qualified domain name has the following syntax.

The fully qualified domain names for the ajax domain and its subdomains are:

ajax.com. 
sales.ajax.com. 
test.ajax.com. 
manf.ajax.com.

Note the dot at the furthest right position of each name.

Zones

DNS service for a domain is managed on the set of name servers. Name servers can manage a single domains or multiple domains, or domains and some or all of their corresponding subdomains. The part of the namespace that a given name server controls is called a zone. Therefore, the name server is said to be authoritative for the zone. If you are responsible for a particular name server, you might be given the title “Zone Administrator”.

The data in a name server's database are called zone files. One type of zone file stores IP addresses and host names. When someone attempts to connect to a remote host using a host name by a utility like ftp or telnet, DNS performs name-to-address mapping, by looking up the host name in the zone file and converting it into its IP address.

Figure 3–6 Domains and Zones

For example, the Ajax domain shown in the above contains a top domain (Ajax), four subdomains, and five sub-subdomains. It is divided into four zones.. Thus, the Ajax name server administers a zone composed of the Ajax, Sales, Retail, and Wholesale domains. The Manf and QA domains are zones unto themselves served by their own name servers, and the Corp name server manages a zone composed of the Corp, Actg, Finance, and Mktg domains.

Reverse Mapping

The DNS database also includes zone files that use the IP address as a key to find the host name of the machine, enabling IP address to host name resolution. This process is called reverse resolution or more commonly, reverse mapping. Reverse mapping is used primarily to verify the identity of the machine that sent a message or to authorize remote operations on a local host.

The in-addr.arpa Domain

The in-addr.arpa domain is a conceptual part of the DNS namespace that uses IP addresses for its leaves, rather than domain names. It is the part of your zone that enables address-to-name mapping.

Just as DNS domain names are read with the lowest level subdomain occupying the furthest left position and the root at the far right, in-addr.arpa domain IP addresses are read from lowest level to the root. Thus, the IP addresses are read backward. For example, suppose a host has the IP address 192.168.21.165. In the in-addr.arpa zone files, its address is listed as 165.21.168.192.in-addr.arpa. with the dot at the end indicating the root of the in-addr.arpa domain.

Chapter 4 Administering DNS (Tasks)

This chapter describes how to administer the Domain Name System (DNS).

The chapter covers the following topics.

• Setting Up the resolv.conf File

• Configuring a Network For DNS

• How to Add DNS Compatibility and +/- Syntax

• Setting up DNS Servers

• Modifying DNS Data Files

• Adding and Deleting Clients

• Enabling a Client to Use IPv6

• Creating DNS Subdomains

• Solaris DNS BIND 8.2.4 Implementation

• DNS Forwarding

Setting Up the resolv.conf File

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

Example 4–1 Sample resolv.conf File for DNS Server

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

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

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

The second line identifies the server itself in the form:

nameserver 192.168.0.0

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

nameserver IP_address

IP_address is the IP address of a slave 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.

Configuring a Network For DNS

To configure a network for DNS, you must set up a client and a server.

Setting Up a DNS Client

Set up the client(s) prior to setting up the DNS server.

How to Set up a DNS Client

1. Create the /etc/resolv.conf file.

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

   ---

   Example 4–2 Sample resolv.conf File

   
   

   ; Sample resolv.conf file for the machine polaris domain doc.com ; try local name server nameserver 10.0.0.1 ; if local name server down, try these servers nameserver 192.168.16.6 nameserver 192.168.16.7 ; 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 following 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 10.0.0.1

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

   nameserver IP_address

   IP_address is the IP address of a master or slave 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

   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.

2. Modify the /etc/nsswitch.conf file.

   NIS. If your master enterprise-level naming service is NIS, with proper configuration, NIS is already DNS-enabled.

   Files-based. If your master enterprise-level naming service is based on /etc files, or if your master enterprise-level naming service is NIS+, do the following.

   1. Become superuser.

   2. Open the /etc/nsswitch.conf file.

   3. DNS can be the only source or an additional source for the hosts information. Locate the hosts line and use DNS in one of the ways shown below.

      hosts: files dns

      or

      hosts: nis dns [NOTFOUND=return] files

      or

      hosts: dns nis [NOTFOUND=return] files

      Do not use the above syntax for NIS clients, or they will be forced to search for unresolved names twice in DNS.

   4. Specify DNS as a source of hosts information.

   5. Save the file and reboot.

Setting Up a DNS Server

How to Set Up a DNS Server

1. Become superuser.

2. Set the server up as a DNS client (this includes setting up the server's resolv.conf file). See Setting Up a DNS Client.

3. Set up the boot file. See Example Boot Files.

4. Set up the data files. You need to set up four data files.

   • named.ca

   • hosts

   • hosts.rev

   • named.local

5. Initialize the server. See Initializing the Server.

6. Test the server. See Testing Your Installation.

   ---

   Note –

   The most common use of DNS is to connect your network to the Internet. 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.

   ---

How to Specify a Master Server

The two types of master server are as follows.

• Zone master server. Each zone has one server that is designated as the master master server for that zone. A zone's master master server is the authoritative server for that zone.

• Zone slave server. A zone can have one or more slave master servers. Slave master servers obtain their DNS data from the zone's master server.

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

1. Create the master record for the zone.

   This record designates the server as a master server for the zone and tells the server where to find the authoritative hosts file. A “master” record has three fields.

   • The first field designates the server as master.

   • The second field identifies the zone the master serves.

   • The third field identifies the hosts file.

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

   master doc.com db.doc

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

   This record designates the server as a master server for the zone's reverse address map, that is, the reverse address domain for doc.com. The record also tells the server where to find the authoritative hosts file. This record has three fields. The first field designates the server as master, 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 10.0.0. In that case, the reverse address domain would be 0.0.10.in-addr.arpa.

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

   master 0.0.10.in-addr.arpa doc.rev

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

   This record designates the server as a master 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 master, 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.10.in-addr.arpa.

   ---

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

   master 0.0.10.in-addr.arpa named.local

How to Specify a Slave Server

A slave server maintains a copy of the data for the zone. The master server sends its data and delegates authority to the slave server. Clients can query a slave server for DNS information. By using slave servers, you can improve response time and reduce network overhead by spreading the load over multiple machines. Slave servers also provide redundancy in case the master server is not available.

When in.named starts, it requests all the data for the given zone from the master. The slave server then periodically checks with the master to see if it needs to update its database. The process of sending the most recent zone database from the master to the slave is called a zone transfer. Thus, you do not modify data files on a slave server, you modify the data files on the zone's master server and the slave servers update their files from the master.

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

A slave record has three required fields:

• The first field designates the server as slave.

• The second field identifies the zone it serves.

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

A “slave” record can have one or more optional fields after the required fields. The optional fields are:

• slave servers

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

• Backup file

  After the IP address of the master (and optional slave) servers, you can add the name of a backup hosts file. If a backup file name is present, the slave server loads its data from that file, then checks with the master (and optional slave) 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 master server.

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

 
slave   doc.com   129.146.168.119  192.146.168.38  doc.com.bakup
slave   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 dnsslave server, which is an alias for the sirius machine whose IP address is 192.146.168.38.

A server can act as the master server for one or more zones, and as the slave server for one or more zones. The mixture of entries in the boot file determines whether a server is a master or slave server for a given zone.

How to Specify a Cache-Only or Stub Server

All servers are caching servers in the sense that they all maintain a cache of DNS data. A caching only or stub server is a server that is not a master server for any zone other than the in-addr.arpa. domain.

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.

The following is a sample boot file for a cache only server.

Example 4–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
master                 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 slave or master authority lines in the boot file, except as noted below.

A cache-only server requires the following.

• A directory line in the boot file

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

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

How to Add DNS Compatibility and +/- Syntax

This section describes how to add compatibility with the +/- syntax used in the /etc/passwd, /etc/shadow, and /etc/group files when you are using either NIS or NIS+ as your master naming service.

1. Become superuser.

2. Open the /etc/nsswitch.conf file.

3. Change the passwd and groups sources to compat.

   • For use with NIS, enter:

     passwd: compat group: compat

   • For NIS+, enter:

     passwd: compat passwd_compat: nisplus group: compat group_compat: nisplus

   This provides the same syntax as in the Solaris 1.x release. It looks up /etc files and NIS maps as indicated by the +/- entries in the files.

4. Add -+ or -+ netgroup to the /etc/passwd, /etc/shadow, and /etc/group files.

   ---

   Note –

   If you fail to add the -+ or -+ netgroup entries to /etc/shadow and /etc/passwd, you will not be able to log in.

   ---

5. Save the file and reboot the system.

   Because some library routines do not periodically check the nsswitch.conf file to see whether it has been changed, you must reboot the machine to make sure those routines have the latest information in the file.

Setting up DNS Servers

Initializing the Server

To initialize a server, do the following.

How to initialize the server

1. Become superuser.

2. Install the named.conf configuration file and the required data files, as described in the previous sections.

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

How to Test Your Installation

1. Become superuser.

2. Check your syslog file for error messages.

   See Chapter 6, DNS Troubleshooting (Reference) for common DNS error messages and troubleshooting information.

3. Look up a host name in the local domain using the nslookup command.

   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 might mean that your server is not correctly listed in the boot file or hosts files.

   • If you get a can't find name or non-existent domain type of message, it might 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.

4. 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 the following.

   dnsmaster% nslookup internic.net

   Server: dnsmaster.doc.com Address: 192.168.168. Name: internic.net Addresses: 192.168.0.9, 192.168.0.6, 192.168.0.5, 192.168.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, the answer will be returned as non-authoritative. This is normal because the answer is now coming from your cache, not the remote name server.

5. 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. The first argument is the name of the host for which you are searching, and the second argument is the name of the name server you are testing.

   remotemachine9% nslookup altair remotemaster.foo.org.

   Server: remotemaster.foo.org Address: 192.168.0.1 Name: altair.doc.com Addresses: 192.168.1.2

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

Adding Additional Servers

You can add primary and secondary DNS servers to your network.

How to Add Additional Servers

1. Become superuser.

2. Set up the server as a DNS client. See Adding a Client.

3. Set up the following files.

   • boot file
   • named.ca
   • hosts
   • hosts.rev
   • named.local

   See Setting up DNS Servers for details.

Modifying DNS Data Files

Whenever you add or delete a host or make some other change in one of the DNS data files in the master DNS server or otherwise modify DNS data files, you must also do the following.

• Change the serial number in the SOA resource record so the slave servers modify their data accordingly see How to Change the SOA Serial Number.

• Inform in.named on the master server that it should reread the data files and update its internal database. See Forcing in.named to Reload DNS Data.

How to Change the SOA Serial Number

Every DNS database file begins with a Start of Authority (SOA) resource record. Whenever you alter any data in a DNS database file, you must increment the SOA serial number by one integer.

For example, if the current SOA Serial Number in a data file is 101, and you make a change to the file's data, you must change 101 to 102. If you fail to change the SOA serial number, the domain's slave servers will not update their copy of the database files with the new information and the master and slave servers will become out of sync.

A typical SOA record of a sample hosts file looks like the following.

; sample  hosts  file
@	IN       SOA 	nismaster.doc.com. root.nismaster.doc.com. (
			109 ; Serial
			10800 ; Refresh
 	                1800 ; Retry
			3600000 ; Expire
			86400 ) ; Minimum

Thus, if you made a change to this hosts file, you would change 109 to 110. The next time you change the file, you would change 110 to 111.

Forcing in.named to Reload DNS Data

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

How to force in.named to reload DNS data.

1. Become superuser.

2. # kill -HUP `cat /etc/named.pid`

This will eliminate all previously cache, and the caching process will start over again.

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

Adding and Deleting Clients

When you add or delete a client, always make your changes in the data files stored on your master DNS server. Do not make changes or edit the files on your slave servers because those will be automatically updated from the master server based on your changing the SOA serial number.

Adding a Client

To add a client to a DNS domain, you set the new machine up as a DNS client and then add records for the new machine to the appropriate hosts and hosts.rev files.

For example, to add the host rigel to the doc.com domain, do the following.

How to Add a Client

1. Become superuser.

2. Create a /etc/resolv.conf file on rigel.

3. Add dns to the hosts line of rigel's /etc/nsswitch.conf file

   See DNS and Internet Access.

4. Add an address (A) record for rigel to the master server's hosts file.

   rigel IN A 192.168.112

5. Add any additional optional records for rigel to the master server's hosts file.

   Optional records could include the following.

   • Alias (CNAME)

   • Mail exchange (MX)

   • Well known services (WKS)

   • Host information (HINFO)

6. Add a PTR record for rigel to the hosts.rev file.

7. Increment the SOA serial number in the master server's hosts and hosts.rev files.

8. Reload the server's data.

   Either reboot the server or type the following.

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

Removing a Client

To remove a client from a DNS domain do the following.

How to Remove a Client

1. Become superuser.

2. Remove dns from the hosts line of the machine's nsswitch.conf file.

3. Remove the machine's /etc/resolv.conf file.

4. Delete the records for that machine from the master server's hosts and hosts.rev files.

5. If the machine has CNAME records pointing to it, those CNAME records must also be deleted from the hosts file.

6. Set up replacements for services supported by the removed machine.

   If the machine is a master server, mail host, or host for any other necessary process or service, you must take whatever steps are necessary to set up some other machine to perform those services.

Enabling a Client to Use IPv6

How to Enable a Client to Use IPv6

1. Become superuser.

2. Edit the /etc/nsswitch.conf file.

3. Add the new ipnodes source and specify the naming service, such as LDAP.

   ipnodes: ldap [NOTFOUND=return] files

   ipnodes defaults to files. During the transition from IPv4 to IPv6, where all naming services are not aware of IPv6 addresses, you should accept the files default. Otherwise, unnecessary delays might result during the resolution of addresses.

4. Save the file and reboot the machine.

   Because the nscd daemon caches this information, which it reads at start up, you must reboot the machine now.

Creating DNS Subdomains

As your network grows you might find it convenient to divide it into one or more DNS subdomains. See The DNS Namespace Hierarchy for a discussion of DNS domain hierarchy and structure.

When you divide your network into a parent domain and one or more subdomains, you reduce the load on individual DNS servers by distributing responsibility across multiple domains. In this way you can improve network performance. For example, suppose there are 900 machines on your network and all of them are in one domain. In this case, one set of DNS servers composed of a master and additional slave and caching-only servers have to support 900 machines. If you divide this network into a parent domain and two subdomain, each with 300 machines, then you have three sets of master and slave servers each responsible for only 300 machines.

By dividing your network into domains that match either your geographic or organizational structure (or both), the DNS domain names indicate where a given machine or email address fits into your structure. For example, rigel@alameda.doc.com implies that the machine rigel is located at your Alameda site, and the email address barnum@sales.doc.com implies that the user barnum is part of your Sales organization.

Dividing your network into multiple domains requires more set up work than keeping everything in one domain, and you have to maintain the delegation data that ties your domains together. On the other hand, when you have multiple domains, you can distribute domain maintenance tasks among different administrators or teams, one for each domain.

Planning Your Subdomains

The following are some points to consider before dividing your network into a parent and one or more subdomains.

• Number of subdomains. The more subdomains your create, the more initial setup work you have to do and the more ongoing coordination work for the administrators in the parent domain. The more subdomains, the more delegation work for the servers in the parent domain. On the other hand, fewer domains mean larger domains, and the larger a domain is the more server speed and memory is required to support it.

• Network divisions. You can divide your network into multiple domains any way you want. The three most common methods are by organizational structure where you have separate subdomains for each department or division (sales, research, manufacturing, for example) by geography where you have separate subdomains for each site, or by network structure where you have separate subdomains for each major network component. The most important rule to remember is that administration and use will be easier if your domain structure follows a consistent, logical, and self-evident pattern.

• Future considerations. The most confusing domain structures are those that grow over time with subdomains added haphazardly as new sites and departments are created. To the degree possible, try to take future growth into account when designing your domain hierarchy. Also take into account stability. It is best to base your subdomains on what is most stable. For example, if your geographic sites are relatively stable but your departments and divisions are frequently reorganized, it is probably better to base your subdomains on geography rather than organizational function. On the other hand, if your structure is relatively stable but you frequently add or change sites, it is probably better to base your subdomains on your organizational hierarchy.

• Wide area network links. When a network spans multiple sites connected via modems or leased lines, performance will be better and reliability greater if your domains do not span such Wide Area Network (WAN) links. In most cases, WAN links are slower than contiguous network connections and more prone to failure. When servers have to support machines that can only be reached over a WAN link, you increase the network traffic funneling through the slower link, and if there is a power failure or other problem at one site, it could affect the machines at the other sites. (The same performance and reliability considerations apply to DNS zones. As a general rule of thumb, it is best if zones do not span WAN links.)

• NIS+ compatibility. If your enterprise-level naming service is NIS+, administration will be easier if your DNS and NIS+ domain and subdomain structures match.

• Subdomain names. To the degree possible, it is best to establish and follow a consistent policy for naming your subdomains. When domain names are consistent, it is much easier for users to remember and correctly specify them. Note that domain names are an important element in all of your DNS data files and that changing a subdomain name requires editing every file in which the old name appears. Thus, it is best to choose subdomain names that are stable and unlikely to need changing. You can use either full words, such as manufacturing, or abbreviations, such as manf, as subdomain names, but it will confuse users if some subdomains are named with abbreviations and others with full names. If you decide to use abbreviations, use enough letters to clearly identify the name because short cryptic names are hard to use and remember. Do not use reserved top-level Internet domain names as subdomain names. This means that names like org, net, com, gov, edu, and any of the two-letter country codes such as jp, uk, ca, and it should never be used as a subdomain name.

Setting Up a Subdomain

In most cases, new subdomains are usually created from the start with a new network and machines, or split off from an existing domain. The process is essentially similar in both cases.

Once you have planned your new subdomain, do the following.

How to Set up a Subdomain

1. Make sure all of the machines in the new subdomain are properly set up as DNS clients.

   If you are carving a new subdomain out of an existing domain, most of the machines are probably already set up of DNS clients. If you are building a new subdomain from scratch or adding new machines to an existing network, you must install properly configured resolv.conf and nsswitch.conf files on each machine.

2. Install properly configured boot and DNS data files on the subdomain's master server.

   • /etc/named.conf.

   • /var/named/named.ca.

   • /var/named/hosts.

   • /var/named/hosts.rev.

   • /var/named/named.local.

   Note that the server host files must have an Address (A) record, any necessary CNAME records for each machine in the subdomain and the server hosts.rev files must have a pointer (PTR) record for each machine in the subdomain. Optional HINFO and WKS records can also be added.

3. If you are splitting an existing domain, remove the records for the machines in the new subdomain from the parent domain's master server hosts and hosts.rev files.

   You must delete the A records for the machines that are now in the new subdomain from the hosts files of the old domain's servers. You must also delete the PTR records for those machines from the old domain's hosts.rev files. Any optional HINFO and WKS records for the moved machines should also be deleted.

4. If you are splitting an existing domain, add the new subdomain name to CNAME records in the parent domain's master server hosts and file.

   For example, suppose you are using the machine aldebaran as a fax server and it had the following CNAME record in the hosts file of the parent domain's servers.

   faxserver IN CNAME aldebaran

   In addition to creating a new faxserver CNAME record for aldebaran in the hosts file of the new subdomain's master server, you would also have to change this CNAME record in the parent domain's hosts file to include aldebaran's subdomain as shown below:

   faxserver IN CNAME aldebaran.manf.doc.com

5. Add NS records for the new subdomain's servers to the parent domain's hosts file.

   For example, suppose that your parent domain is doc.com and you are creating a new manf.doc.com subdomain with the machine rigel as manf's master server and aldebaran as the slave server. You would add the following records to the hosts file of doc.com's master server.

   manf.doc.com 99999 IN NS rigel.manf.doc.com 99999 IN NS aldebaran.manf.doc.com

6. Add A records for the new subdomain's servers to the parent domain's hosts file.

   Continuing with the above example, you would add the following records to the hosts file of doc.com's master server.

   rigel.manf.doc.com 99999 IN A 1.22.333.121 aldebaran.manf.doc.com 99999 IN A 1.22.333.136

7. Start up named on the subdomain's servers.

   # /usr/sbin/in.named

   Instead of running in.named from the command line, reboot. See in.named and DNS Name Servers.

Solaris DNS BIND 8.2.4 Implementation

For your convenience, the Solaris operating environment supplies a compiled version of Berkeley Internet Name Domain (BIND) version 8.2.4. 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 operating environment the following choices were made.

• RFC1535. Not implemented because doing so would remove implicit search lists.

• Inverse Queries. Enabled because SunOS 4 nslookup will not work without them.

• Default Domain Name. If the DNS domain name is not set in /etc/resolv.conf, or via the LOCALDOMAIN environment variable, libresolv derives it from the NIS or NIS+ domain name.

• Utility Scripts. The BIND utility scripts are not included in this Solaris release.

• Test Programs. The BIND test programs dig, dnsquery, and host are not included in this Solaris release because their purpose is similar to that of nslookup and nstest.

How to Migrate from BIND 4.9.x to BIND 8.2.4

1. Become superuser.

2. Run the Korn shell script, /usr/sbin/named-bootconf, to convert a BIND 4.9.x named.boot file to a BIND 8.2.4 named.conf file.

In Solaris 9, the named.boot is ignored.

DNS Forwarding

The nsswitch.conf file controls DNS forwarding and Interent access for clients. NIS clients have implicit forwarding capabilities. NIS+ clients do not. See below.

Hot to Enable DNS Forwarding Capabilities on an NIS+ Client

1. Become superuser.

2. Properly configure the hosts line in the /etc/resolve.conf file to read: hosts:nisplus dns files.

In this implementation of NIS, if a /etc/resolve.conf file exists on the server, ypstart automatically starts the ypserv daemon with the -d option to forward requests to DNS. To stop forwarding to DNS, edit the /usr/lib/netsvc/yp/ypstart script to remove the -d option from the ypserv command. You must then reboot the machine.

How to enable DNS forwarding capabilities on an older NIS client

1. Become superuser.

2. Set the YP_INTERDOMAIN key in the hosts.byname map and the hosts.byaddr map by modify the following lines in the Makefile (at the top of the file) from the following.

   #B=-b B=

   to

   B=-b #B=

   Now makedbm starts with the -b flag when making the maps, and inserts the YP_INTERDOMAIN into the ndbm files.

3. Rebuild the maps.

   # /usr/ccs/bin/make hosts

4. Make sure that all NIS servers have an /etc/resolv.conf file that points to valid name server(s).

5. Stop each server with the ypstop command.

   # /usr/lib/netsvc/yp/ypstop

6. Restart each server with the ypstart command.

   # /usr/lib/netsvc/yp/ypstart

   ---

   Note –

   If you have NIS servers that are not running Solaris 2 or higher, make sure that the YP_INTERDOMAIN key is present in the host maps. In addition, problems might arise if the master server and slave server are running differentversions of Solaris. The following table summarizes the commands to issue to avoid such problems. The notation “4.0.3+” means “release 4.0.3 of SunOS or later.” The command makedbm -b is a reference to the “-B” variable in the Makefile.

   ---

   Table 4–2 NIS/DNS in Heterogeneous NIS Domains

   SLAVE	MASTER
   	4.0.3+	Solaris NIS
   4.0.3+	Master: makedbm -b Slave: ypxfr	Master: makedbm -b Slave: ypxfr -b	Master: ypserv -d Slave: ypxfr -b
   Solaris NIS	Master: makedbm -b Slave: ypxfr	Master: makedbm -b Slave: ypxfr	Master: ypserv -d Slave: ypxfr with resolve.conf or ypxfr -b

The Solaris operating environment includes the dynamic library routines that make up the resolver.

Chapter 5 DNS Administration (Reference)

This chapter covers the following topics.

• Implementing DNS

• Setting Up the Data Files

• Setting Up Subdomains

• The DNS Namespace Hierarchy

• How DNS Affects Mail Delivery

• DNS Configuration and Data Files

• Data File Resource Record Format

Implementing DNS

A Practical Example

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

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

This example assumes the following.

• An environment connected to the Internet

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

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

• Each network has its own network number

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

Example Boot Files

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

Example 5–1 Example Boot File for dnsmastr Server

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

Example 5–2 Example Boot File for dnssales Server

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

Example 5–3 Example Boot File for dnssecond Server

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

Example resolv.conf Files

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

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

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

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

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

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

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

Example named.local File

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

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

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

Example hosts Files

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

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

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

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

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

Example hosts.rev Files

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

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

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

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

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

Example name.ca File

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

Example 5–12 Example named.ca File

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

Setting Up the Data Files

All the data files used by the DNS daemon in.named are written in standard resource record format. Each line of a file is a record, called a resource record (RR). Each DNS data file must contain certain resource records.

Resource Record Types

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

In the sample files included in the following sections, @ indicates the current zone or origin and lines that begin with a semicolon (;) are comments.

Setting Up Subdomains

Setting Up Subdomains—Same Zone

The simplest method is to include the subdomain in the parent domain's zone. In this way, one set of DNS servers and data files applies to all the machines regardless of their domain.

The advantage of the same-zone method is simplicity and ease of administration. The disadvantage is that one set of servers has to serve all machines in all of the zone's domains. If there are too many machines, the servers will be overloaded and network performance can decline.

Data files for multi-domain zones must include records for all machines and servers in each domain covered by the zone.

Setting up a multi-domain zone is the same as setting up a zone with a single domain, except that fully qualified domain names are used in the hosts file to identify machines in remote domains. In other words, in the hosts file, when you identify a machine in the server's local domain, you need to use only the machine's name. But when you identify a machine in some other domain, you must identify the machine with a fully qualified domain name in the format: machine.domain.

Server and machine names in hosts.rev and named.local files also need to be fully qualified with domain names. But that is true regardless of whether or not the zone has more than one domain.

Setting Up Subdomains—Different Zones

The advantage of the different-zone method is that you can assign different sets of servers to serve machines in different domains; in that way, you spread out server load so that no group of servers is overloaded. The disadvantage is that setup maintenance is more complicated.

Setting up subdomains that are in different zones is more complicated than including multiple domains in a single zone, because you have to specify how clients in different zones obtain DNS information from the other zones.

To divide a network into multiple domains, create a domain hierarchy. That is, one domain becomes the top domain. Beneath the top domain, you create one or more subdomains. If you want, you can create subdomains of subdomains. But every subdomain has a set place relative to the top domain in the hierarchy of domains. When read from left to right, domain names identify the domain's place in the hierarchy. For example, the doc.com domain is above the sales.doc.com domain, while the west.sales.doc.com domain is below the sales.doc.com domain.

DNS zones acquire a hierarchy from the domains that they contain. The zone containing a network's top domain is the top zone. A zone that contains one or more subdomains below the top domain is below the top zone in the zone hierarchy. When DNS information is passed from one zone to another, it is passed up and down the zone hierarchy. This means that each zone requires records in its data files that specify how to pass information up to the zone immediately above it, and down to any zones immediately below it.

To correctly transfer DNS information from one zone to another in a multi-zone network:

• hosts.rev file. There must be a PTR record in each hosts.rev file pointing to the name of one or more master servers in the zone immediately above it. This type of PTR record is exactly the same as any other PTR record in the file, except that it identifies a server in the zone above.

• hosts file NS records. There must be a zone NS record in each hosts file identifying each name server in each zone immediately below. This type of NS record requires the name of the zone below as the first field in the NS record. (The name of the zone is specified in the SOA record of the zone's host file.)

• hosts file A records. There must be an A record in each hosts file identifying the IP address of each name server in each zone immediately below. This type of A record has to have the name of the zone below as the first field in the A record. (The name of the zone is specified in the SOA record of the zone's host file.)

The example files in the next chapter illustrate a network with two zones.

The DNS Namespace Hierarchy

The entire collection of DNS administrative domains throughout the world are organized in a hierarchy called the DNS namespace. This section shows how the namespace organization affects both local domains and the Internet.

Domains and Subdomains

Like the UNIX^TM file system, DNS domains are organized as a set of descending branches similar to the roots of a tree. Each branch is a domain, each subbranch is a subdomain. The terms domain and subdomain are relative. A given domain is a subdomain relative to those domains above it in the hierarchy, and a parent domain to the subdomains below it.

Figure 5–1 Domains and Subdomains

For example, in Figure 5–1, com is a parent domain to the Acme, Ajax, and AAA domains. Or you could just as easily say that those are subdomains relative to the com domain. In its turn, the Ajax domain is a parent to four subdomains (Sales, Manf, QA, and Corp).

A domain contains one parent (or top) domain plus the associated subdomains if any. Domains are named up the tree starting with the lowest (deepest) subdomain and ending with the root domain.

How DNS Affects Mail Delivery

In addition address mapping and maps addresses to host names, as discussed in Name-to-Address Resolution, DNS also helps mail delivery agents, such as sendmail and POP, deliver mail along the Internet.

To deliver mail across the Internet, DNS uses mail exchange records (MX records). Most organizations do not allow direct delivery of mail that comes across the Internet for hosts within the organization. Instead, they use a central mail host (or a set of mail hosts) to intercept incoming mail messages and route them to their recipients.

The mail exchange record identifies the mail host that services each machine in a domain. Therefore, a mail exchange record lists the DNS domain names of remote organizations and either the IP address or the host name of its corresponding mail host.

DNS Configuration and Data Files

In addition to the in.named daemon, DNS on a name server consists of a boot file called named.conf, a resolver file named resolv.conf, and four types of zone data files.

Names of DNS Data Files

So long as you are internally consistent, you can name the zone data files anything you want. This flexibility can lead to some confusion when working at different sites or referring to different DNS manuals and books.

For example, the file names used in Sun manuals and at most many Solaris sites vary from those used in the book DNS and BIND by Albitz and Liu, O'Reilly & Associates, 1992, and both of those nomenclatures have some differences from that used in the public-domain Name Server Operations Guide for BIND, University of California.

In addition, this manual and other DNS documentation uses generic names that identify a file's main purpose, and specific example names for that file in code record samples. For example, Solaris Naming manuals use the generic name hosts when describing the function and role of that file, and the example names db.doc and db.sales.doc in code samples.

For reference purposes, the following table compares BIND file names from these three sources.

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

The named.conf File

The BIND 8.2.4 configuration file, /etc/named.conf establishes the server as a master, slave, or cache-only name server. It also specifies the zones over which the server has authority and which data files it should read to get its initial data.

The /etc/named.conf file contains statements that implement the following.

• Security through an Access Control List (ACL) that defines a collection of IP addresses that an NIS+ host has read/write access

• Logging specifications

• Selectively applied options for a set of zones, rather than to all zones

The configuration file is read by in.named when the daemon is started by the server's start up script, /etc/init.d/inetsvc. The configuration file directs in.named either to other servers or to local data files for a specified domain.

named.conf Statements

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

The named.conf file supports the following statements.

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

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

logging {
         category queries { default_syslog; };
};

include "/var/named/abcZones.conf"

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

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

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

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

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

The named.ca File

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

Setting Up the named.ca File

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

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

Internet named.ca File

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

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

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

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

Example 5–14 Example Internet named.ca file

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

Non-Internet named.ca File

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

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

ourroot.private.  999999  IN  A  192.1.1.10

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

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

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

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

The hosts File

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

Setting Up the hosts File

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

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

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

Example 5–16 Sample hosts File

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

A hosts file usually contains these elements:

• A Start of Authority (SOA) record

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

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

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

• One or more Mail Exchange (MX) records

The hosts.rev File

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

Setting Up the hosts.rev File

The hosts.rev file sets up inverse mapping.

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

Example 5–17 Sample hosts.rev File

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

A hosts.rev file contains the following elements.

• A Start of Authority (SOA) record

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

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

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

The named.local File

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

Setting Up the named.local File

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

Example 5–18 Sample named.localFile

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

A named.local file contains these elements:

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

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

• A PTR record for localhost

$INCLUDE Files

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

For example, suppose a data file contained following line:

$INCLUDE /etc/named/data/mailboxes

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

Data File Resource Record Format

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

Standard Resource Record Format

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

namettlclassrecord-typerecord-specific-data

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

The name Field

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

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

The ttl Field

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

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

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

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

The class Field

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

The record-type Field

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

The record-specific-data Field

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

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

Special Resource Record Characters

The following characters have special meanings:

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

Control Entries

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

$INCLUDE

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

$INCLUDE /etc/named/data/mailboxes

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

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

$ORIGIN()

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

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

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

Resource Record Types

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

Start-of-Authority record (SOA)

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

Example 5–19 SOA Record Format

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

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

name

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

class

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

SOA

This field is the type of this resource record.

origin

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

person-in-charge

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

serial

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

refresh

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

retry

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

expire

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

ttl

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

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

Example 5–20 Sample SOA Resource Record

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

Name Server (NS)

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

Example 5–21 NS Record Format

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

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

Example 5–22 Sample NS Resource Record

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

Address (A)

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

Example 5–23 Address Record Format

	
machinename	[optional TTL] class A	address

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

Example 5–24 Sample Address Record

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

Host Information (HINFO)

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

Example 5–25 HINFO Record Format

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

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

Example 5–26 Sample HINFO Resource Record

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

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

Well-Known Services (WKS)

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

Example 5–27 WKS Record Format

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

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

Example 5–28 Sample WKS Resource Record

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

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

Canonical Name (CNAME)

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

Example 5–29 CNAME Record Format

 nickname [optional TTL] class CNAME	canonical-name

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

Example 5–30 Sample CNAME Resource Record

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

Pointer Record (PTR)

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

Example 5–31 PTR Record Format

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

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

Example 5–32 Sample PTR Resource Record

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

Mail Exchanger (MX)

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

Example 5–33 MX Record Format

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

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

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

Example 5–34 Sample MX Resource Record

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

Chapter 6 DNS Troubleshooting (Reference)

This chapter described some common DNS problems and how to solve them.

Clients Can Find Machine by Name but Server Cannot

Symptoms

DNS clients can find machines by either IP address or by host name, but the server can only find machines by their IP addresses.

Probable cause and solution

This is most likely caused by omitting DNS from the hosts line of the server's nsswitch.conf file. For example, a bad hosts line might look like this: hosts: files

When using DNS you must include dns in the hosts record of every machine's nsswitch.conf file. For example:

hosts: dns nisplus files

or

hosts: nisplus dns files

Changes Do Not Take Effect or Are Erratic

Symptom

You add or delete machines or servers but your changes are not recognized or do not take effect. Or in some instances the changes are recognized and at other times they are not yet in effect.

Probable cause

The most likely cause is that you forgot to increment the SOA serial number on the master server after you made your change. Since there is no new SOA number, your slave servers do not update their data to match that of the master so they are working with the old, unchanged data files.

Another possible cause is that the SOA serial number in one or more of the master data files was set to a value lower than the corresponding serial number on your slave servers. This could happen, for example, if you deleted a file on the master and then recreated it from scratch using an input file of some sort.

A third possible cause is that you forgot to send a HUP signal to the master server after making changes to the primary's data files.

Diagnosis and solution

First, check the SOA serial numbers in the data file that you changed and the corresponding file on the slave server.

• If the SOA serial number in the master file is equal to, or less than, the serial number in the slave file, increase the serial number on the primary's file so that it is greater than the number in the slave file. For example, if the SOA number in both files is 37, change the number in the primary's file to 38. The next time the slave checks with the primary, it will load the new data. (There are utilities that can force a master to immediately transfer data to the secondaries, if you have one of these utilities you can update the slave without waiting for it to check the primary.)

• Review the syslog output for the most recent named nnnn restarted or named nnn reloading nameserver entry. If the timestamp for that entry is before the time you finished making changes to the file, either reboot the server or force it to read the new data as explained in Forcing in.named to Reload DNS Data.

DNS Client Cannot Lookup “Short” Names

Symptoms

Client can lookup fully qualified names but not short names.

Possible cause and solution

Check the client's /etc/resolv.conf file for spaces at the end of the domain name. No spaces or tabs are allowed at the end of the domain name.

Reverse Domain Data Not Correctly Transferred to slave

While zone domain-named data is properly transferred from the zone master server to a zone slave server, the reverse domain data is not being transferred. In other words, the host.rev file on the slave is not being properly updated from the primary.

Possible causes

Syntax error in the slave server's boot file.

Diagnosis and Solution

Check the slave server's boot file. Make sure that the master server's IP address is listed for the reverse zone entries just as it is for the hosts data.

Server Failed and Zone Expired Problems

When a slave server cannot obtain updates from its master, it logs a master unreachable message. If the problem is not corrected, the slave expires the zone and stops answering requests from clients. When that happens, users start seeing server failed messages.

Symptoms

• Masters for slave zone domain unreachable messages in syslog.

• slave zone domain expired messages in syslog.

• *** domain Can't find name: server failed messages to users.

Note that if the problem is with a slave server, some users could still be successfully obtaining DNS information from the master and thus operating without experiencing any difficulty.

Possible causes

The two most likely causes for these problems are network failure and a wrong IP address for the master in the slave's boot file.

Diagnosis and solution

• Check that the slave's configuration file contains the correct IP address for the master. Check the line:

  zone "someone" { type slave; file "somefile": master [IPaddress; }; };

Make sure that the IP address of the master matches the master's actual IP address and the address for the master specified in the hosts file. If the IP address is wrong, correct it, and then reboot the slave.

• If the master's IP address is correct, make sure the master is up and running correctly by pinging the master's IP address. For example, to ping the master at IP address 192.168.0.1, you would enter the following.

  % ping 192.168.0.1 -n 10

• If the master does not respond to the ping, make sure it is up and running properly.

• If the master is running okay, use ps to make sure it is running named. If it is not running named, reboot it.

• If the master is correctly running named, you most likely have a network problem.

rlogin, rsh, and ftp Problems

Symptoms

• Users are asked for password when they try to rlogin to a machine in another domain over the Internet.

• Users are denied access when they try to ftp to a machine in another domain over the Internet.

• Users are denied access when they try to use rlogin or rsh to a machine on their own network.

Possible causes

• The user is working at a machine that does not have a PTR record in the master server's hosts.rev file.

• A missing or incorrect delegation of a subdomain in the hosts.rev file.

Diagnosis and solution

Check the appropriate hosts.rev file and make sure there is a PTR record for the user's machine. For example, if the user is working at the machine altair.doc.com with an IP address of 192.168.0.1, the doc.com master server's doc.rev file should have an entry like:

46 	IN	 PTR 	altair.doc.com.

If the record is missing, add it to the hosts.rev file and then reboot the server or reload its data as explained in Forcing in.named to Reload DNS Data.

Check and correct the NS entries in the hosts.rev files and then reboot the server or reload its data as explained in Forcing in.named to Reload DNS Data.

Other DNS Syntax Errors

Symptoms

Error messages in console or syslog with operative phrases like the following are most often caused by syntax errors in DNS data and boot files.

• No such...

• Unknown field...

• Non-authoritative answer:

• Database format error...

• illegal or (illegal)

• error receiving zone transfer

Check the relevant files for spelling and syntax errors.

A common syntax error is misuse of the trailing dot in domain names (either using the dot when you should not, or not using it when you should). See Setting up DNS Servers.