System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)

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

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

Note –

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

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.

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

Become superuser.

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

Set up the boot file. See Example Boot Files.

Set up the data files. You need to set up four data files.
- named.ca
- hosts
- hosts.rev
- named.local

Initialize the server. See Initializing the Server.

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.

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

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

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.

Note –

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.

Become superuser.

Open the /etc/nsswitch.conf file.

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.

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.

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

Become superuser.

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

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

Become superuser.

Check your syslog file for error messages.

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

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.

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.

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

Become superuser.

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

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.

Become superuser.

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

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

Caution –

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

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

Become superuser.

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

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

See DNS and Internet Access.

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

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)

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

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

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

Become superuser.

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

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

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

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

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

Table 4–1 Enabling a Machine to Use IPv6


Task		Description	For Instructions, Go To
Enabling a Machine to Use IPv6		Modify the `/etc/nsswitch.conf` file and enable an NIS+ client to use IPv6	See below.

How to Enable a Client to Use IPv6

Become superuser.

Edit the /etc/nsswitch.conf file.

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.

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

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.

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.

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.

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

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

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

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

Become superuser.

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.

Note –

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

Become superuser.

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

Become superuser.

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.

Rebuild the maps.

# /usr/ccs/bin/make hosts

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

Stop each server with the ypstop command.

# /usr/lib/netsvc/yp/ypstop

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 4 Administering DNS (Tasks)

Setting Up the resolv.conf File

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

Configuring a Network For DNS

Setting Up a DNS Client

How to Set up a DNS Client

Example 4–2 Sample resolv.conf File

Setting Up a DNS Server

How to Set Up a DNS Server

How to Specify a Master Server

How to Specify a Slave Server

How to Specify a Cache-Only or Stub Server

Example 4–3 Sample Master Boot File for Caching-only Server

How to Add DNS Compatibility and +/- Syntax

Setting up DNS Servers

Initializing the Server

How to initialize the server

Testing Your Installation

How to Test Your Installation

Adding Additional Servers

How to Add Additional Servers

Modifying DNS Data Files

How to Change the SOA Serial Number

Forcing in.named to Reload DNS Data

How to force in.named to reload DNS data.

Adding and Deleting Clients

Adding a Client

How to Add a Client

Removing a Client

How to Remove a Client

Enabling a Client to Use IPv6

How to Enable a Client to Use IPv6

Creating DNS Subdomains

Planning Your Subdomains

Setting Up a Subdomain

How to Set up a Subdomain

Solaris DNS BIND 8.2.4 Implementation

How to Migrate from BIND 4.9.x to BIND 8.2.4

DNS Forwarding

Hot to Enable DNS Forwarding Capabilities on an NIS+ Client

How to enable DNS forwarding capabilities on an older NIS client

Setting Up the `resolv.conf` File

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

Example 4–2 Sample `resolv.conf` File

How to Change the `SOA` Serial Number

Forcing `in.named` to Reload DNS Data