As your network grows, you might want to divide the network into 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 subdomains, you reduce the load on individual DNS servers by distributing responsibility across multiple domains. Network performance then improves.
By dividing your network into geographic or organizational subdomains, 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. The email address barnum@sales.doc.com implies that the user barnum is part of your Sales organization.
The division of a network into multiple domains requires more set up work. 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 domain administrators.
The following points are to be considered before dividing your network into a parent and subdomains.
Number of subdomains. More subdomains means more setup work and more ongoing coordination work for the parent domain administrators in the parent domain. On the other hand, fewer domains mean larger domains. The larger a domain is, the more server speed and memory is required for support.
Network divisions. You can divide your network into multiple domains however you see fit. Remember that administration is easier if your domain structure follows a consistent, logical, and self-evident pattern.
Future considerations. The most confusing domain structures have subdomains that are added haphazardly to accommodate new sites and new departments. Try to take future growth into account when designing your domain hierarchy. Take into account stability. Base your subdomains on what is most stable. For example, if your geographic sites are relatively stable but your departments frequently reorganize, base your subdomains on geography rather than organizational function. On the other hand, if your structure is stable but you frequently add sites, base your subdomains on your organizational hierarchy.
Wide area network (WAN) links. Performance will be better and reliability greater if your domains do not span the WAN. In most cases, WAN links are slower than contiguous network connections and more prone to failure. When servers support machines that can only be reached over a WAN link, more network traffic is funneled through the slower link. If there is a power failure or other problem at one site, machines at the other sites could be affected. The same performance and reliability considerations apply to DNS zones. As a general rule of thumb, zones should not span WAN links.
NIS+ compatibility. If your enterprise-level naming service is NIS+, administration is easier if your DNS and NIS+ domain and subdomain structures match.
Subdomain names. Establish and follow a consistent policy for naming your subdomains. When domain names are consistent, users are more apt to remember and correctly specify the names. Domain names are an important element in all of your DNS data files. If a subdomain name is changed, every file in which the old name appears must be edited. Therefore, choose subdomain names that are stable and unlikely to need changing. Use either full words, such as manufacturing, or abbreviations, such as manf, as subdomain names. However, users might be confused 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. 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.
In most cases, new subdomains are usually created from the start with a new network and new 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.
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 add new machines to an existing network, you must install properly configured resolv.conf and nsswitch.conf files on each machine.
Install properly configured configuration and DNS zone 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
The server host files must have an Address (A) record along with any necessary CNAME records for each machine in the subdomain. The server hosts.rev files must have a pointer (PTR) record for each machine in the subdomain. HINFO and WKS records can also be added.
If you are splitting a domain, remove the new subdomain machines records from the 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 divide an existing domain, add the new subdomain name to CNAME records in the master server's hosts file.
For example, suppose you use the machine aldebaran as a fax server. The fax server has the following CNAME record in the hosts file of the parent domain's servers.
faxserver IN CNAME aldebaran |
You would create a faxserver CNAME record for aldebaran in the new master server's hosts file. You would also change this CNAME record in the parent domain's hosts file to include aldebaran's subdomain:
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, say your parent domain is doc.com. You create a new manf.doc.com subdomain with the machine rigel as manf's master server. aldebaran is 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.
You would then 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 in.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.