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