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.^[6] Since a zone is bounded by delegation, it will never include delegated data.

^[6] 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, 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 a 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 secondaries. A primary master name server for a zone reads the data for the zone from a file on its host. A secondary name server for a zone gets the zone data from another name server 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 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 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 secondary name servers for a zone are authoritative for that zone. Despite the somewhat disparaging name, secondaries 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 secondary name servers that load their data from the primary master for the zone. The secondaries you set up will transfer new zone data when necessary.

Secondary name servers are important because it's a good idea to set up more than one authoritative 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 secondary name servers makes this administratively workable.

Calling a particular name server a primary master name server or a secondary 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 secondary for another. Most name servers, however, are either primary for most of the zones they load or secondary for most of the zones they load. So if we call a particular name server a primary or a secondary, we mean that it's the primary master or a secondary for most of the zones for which it's authoritative.

2.4.3 Datafiles

The files from which primary master name servers load their zone data are called, simply enough, zone datafiles. We often refer to them as datafiles. Secondary name servers can also load their zone data from datafiles. Secondaries are usually configured to back up the zone data they transfer from a master name server to datafiles. If the secondary is later killed and restarted, it will read the backup datafiles 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.