 |  |
2.4. Name Servers and Zones
The programs that store information about the domain name space are called name servers. Name servers generally have complete information about some part of the domain name space (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 would contain mostly delegation information for 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 a totally different group of authoritative name servers.
Figure 2-9. The berkeley.edu domain broken into zones
A zone and a domain may share the same domain name but contain different nodes. In particular, the zone doesn't contain any nodes 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 subdomains 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. But the zone ca contains only the data in ca (see Figure 2-10), which is probably mostly pointers to the delegated subdomains. And ab.ca, on.ca, and qc.ca are separate zones from the ca zone.
Figure 2-10. The domain ca . . .
If a subdomain of the domain isn't delegated away, however, the zone contains the domain names and data in the subdomain. So the bc.ca and sk.ca (British Columbia and Saskatchewan) subdomains of the ca domain may exist, but might not be delegated. (Perhaps the provincial authorities in B.C. and Saskatchewan aren't yet ready to manage their own zones, but the authorities running the top-level ca zone 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-11. . . . versus the zone ca
Now it's clear why name servers load zones instead of domains: a domain might contain more information than the name server needs.[12] A domain could contain data delegated to other name servers. Since a zone is bounded by delegation, it never includes delegated data.[12]Imagine if a root name server loaded the root domain instead of the root zone: it would be loading the entire namespace!If you're just starting out, however, your domain probably won't have any subdomains. In this case, since there's no delegation going on, your domain and your zone 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 subdomains 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 talk to.
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 another name server that is authoritative for the zone, called its master server. Quite often, the master name 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 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 much software, including Microsoft's DNS Manager) 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 fool with copying 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. Once they're set up, the slaves 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 ensure 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 it's authoritative for.
2.4.3. Zone 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 or database 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.The data files contain resource records that describe the zone. The resource records describe all the hosts in the zone and mark any delegation of subdomains. BIND also allows special directives to include the contents of other data files in a zone data file, much like the #include statement in C programming.
|  | |
| 2.3. Delegation |  | 2.5. Resolvers |
