2.4 Name Servers and Zones
The programs that store information about the domain namespace are called name servers . Name servers generally have complete information about some part of the domain namespace, called a zone , which they load from a file or from another name server. The name server is then said to have authority for that zone. Name servers can be authoritative for multiple zones, too.
The difference between a zone and a domain is important, but subtle. All top-level domains and many domains at the second level and lower, such as berkeley.edu and hp.com , are broken into smaller, more manageable units by delegation. These units are called zones. The edu domain, shown in Figure 2-8, is divided into many zones, including the berkeley.edu zone, the purdue.edu zone, and the nwu.edu zone. At the top of the domain, there's also an edu zone. It's natural that the folks who run edu would break up the edu domain: otherwise , they'd have to manage the berkeley.edu subdomain themselves . It makes much more sense to delegate berkeley.edu to Berkeley. What's left for the folks who run edu ? The edu zone, which contains mostly delegation information for the subdomains of edu .
Figure 2-8. The edu domain broken into zones
The berkeley.edu subdomain is, in turn , broken up into multiple zones by delegation, as shown in Figure 2-9. There are delegated subdomains called cc , cs , ce , me , and more. Each of these subdomains is delegated to a set of name servers, some of which are also authoritative for berkeley.edu . However, the zones are still separate and may have totally different groups of authoritative name servers.
Figure 2-9. The berkeley.edu domain broken into zones
A zone contains all the domain names the domain with the same domain name contains, except for domain names in delegated subdomains. For example, the top-level domain ca (for Canada) has subdomains called ab.ca , on.ca , and qc.ca , for the provinces Alberta, Ontario, and Quebec. Authority for the ab.ca , on.ca , and qc.ca domains may be delegated to name servers in each of the provinces. The domain ca contains all the data in ca plus all the data in ab.ca , on.ca , and qc.ca . However, the zone ca contains only the data in ca (see Figure 2-10), which is probably mostly pointers to the delegated subdomains. ab.ca , on.ca , and qc.ca are separate zones from the ca zone.
The zone also contains the domain names and data in any subdomains that aren't delegated away. For example, the bc.ca and sk.ca (British Columbia and Saskatchewan) subdomains of the ca domain may exist but not be delegated. (Perhaps the provincial authorities in B.C. and Saskatchewan aren't yet ready to manage their subdomains, but the authorities running the top-level ca domain want to preserve the consistency of the namespace and implement subdomains for all of the Canadian provinces right away.) In this case, the zone ca has a ragged bottom edge, containing bc.ca and sk.ca , but not the other ca subdomains, as shown in Figure 2-11.
Figure 2-10. The domain ca...
Figure 2-11. ...versus the zone ca
Now it's clear why name servers load zones instead of domains: a domain may contain more information than the name server needs, since it can contain data delegated to other name servers.  Since a zone is bounded by delegation, it will never include delegated data.
If you're just starting out your domain probably won't have any subdomains. In this case, since there's no delegation going on, your domain and your zone will contain the same data.
2.4.1 Delegating Subdomains
Even though you may not need to delegate parts of your domain just yet, it's helpful to understand a little more about how the process of delegating a subdomain works. Delegation, in the abstract, involves assigning responsibility for some part of your domain to another organization. What really happens, however, is the assignment of authority for your subdomain to different name servers. (Note that we said "name servers," not just "name server.")
Your zone's data, instead of containing information in the subdomain you've delegated, includes pointers to the name servers that are authoritative for that subdomain. Now if one of your name servers is asked for data in the subdomain, it can reply with a list of the right name servers to contact.
2.4.2 Types of Name Servers
The DNS specs define two types of name servers: primary masters and secondary masters. A primary master name server for a zone reads the data for the zone from a file on its host. A secondary master name server for a zone gets the zone data from the name server that is authoritative for the zone, called its master server. Quite often, the master server is the zone's primary master, but that's not required: a secondary master can load zone data from another secondary. When a secondary starts up, it contacts its master name server and, if necessary, pulls the zone data over. This is referred to as a zone transfer . Nowadays, the preferred term for a secondary master name server is a slave , though many people (and some software, including Microsoft's DNS console) still use the old term.
Both the primary master and slave name servers for a zone are authoritative for that zone. Despite the somewhat disparaging name, slaves aren't second-class name servers. DNS provides these two types of name servers to make administration easier. Once you've created the data for your zone and set up a primary master name server, you don't need to copy that data from host to host to create new name servers for the zone. You simply set up slave name servers that load their data from the primary master for the zone. The slaves you set up will transfer new zone data when necessary.
Slave name servers are important because it's a good idea to set up more than one name server for any given zone. You'll want more than one for redundancy, to spread the load around, and to make sure that all the hosts in the zone have a name server close by. Using slave name servers makes this administratively workable .
Calling a particular name server a primary master name server or a slave name server is a little imprecise, though. We mentioned earlier that a name server can be authoritative for more than one zone. Similarly, a name server can be a primary master for one zone and a slave for another. Most name servers, however, are either primary for most of the zones they load or slave for most of the zones they load. So if we call a particular name server a primary or a slave, we mean that it's the primary master or a slave for most of the zones for which it's authoritative.
2.4.3 Data Files
The files from which primary master name servers load their zone data are called, simply enough, zone data files . We often refer to them as data files . Slave name servers can also load their zone data from data files. Slaves are usually configured to back up the zone data they transfer from a master name server to data files. If the slave is later killed and restarted, it will read the backup data files first, then check to see whether its zone data is current. This both obviates the need to transfer the zone data if it hasn't changed and provides a source of the data if the master is down.