9.2 Adding More Name Servers

When you need to create new name servers for your domain, the simplest recourse is to add secondaries. You already know how—we went over it in Chapter 4—and once you've set up one secondary, cloning it is a piece of cake. But you can run into trouble if you add secondaries indiscriminately.

If you run a large number of secondary name servers for a zone, the primary master name server can take quite a beating just keeping up with the secondaries' polling to check that their zone data is current. There are a number of courses of action to take for this problem, as described in the sections that follow:

• Eliminate the secondary name servers altogether by using Active Directory integration.

• Increase the refresh interval so that the secondaries don't check so often.

• Direct some of the secondary name servers to load from other secondary name servers.

• Create caching-only name servers.

• Create partial-secondary name servers.

9.2.1 Active Directory Integration

We discuss Active Directory in Chapter 8. Briefly, this feature eliminates the load on the primary master from secondaries' polling by eliminating the secondaries! Remember that the main purpose of the primary master/secondary relationship is zone data replication: the DNS designers created the zone transfer mechanism as a way to spread zone data among multiple authoritative name servers. Windows stores all kinds of information about the network in Active Directory and replicates this information, too. With Windows Server 2003, you have the option of storing the definitive version of your zones' data in Active Directory rather than in zone datafiles on the primary master. All name servers running on domain controllers load the zone data stored in Active Directory, which also takes care of replicating changes to the data. See Chapter 8 for more details and instructions on setting up Active Directory.

9.2.2 Secondary Servers

You can have some of your secondaries load zone data from other secondary name servers instead of from a primary name server. The secondary name server can't tell if it's loading from a primary or another secondary. It's only important that the name server serving the zone transfer is authoritative for the zone. There's no trick to configuring this. Instead of specifying the IP address of the primary in the secondary's configuration, you simply specify the IP address of another secondary

When you go to this second level of distribution, though, be aware that it can take up to twice as long for the data to percolate from the primary name server to all the secondaries. Remember that the refresh interval is the period after which the secondary servers check to make sure that their zone data is still current. Therefore, it can take the first-level secondary servers the entire length of the refresh interval to get a new copy of the zone from the primary master server. Similarly, it can take the second-level secondary servers the entire refresh interval to get a new copy of the zone from the first-level secondary servers. The propagation time from the primary master server to all the secondary servers can therefore be twice the refresh interval.

Fortunately, using the DNS NOTIFY feature, which we'll describe in Chapter 11, avoids this delay. This feature is on by default and triggers zone transfers soon after the zone is updated on the primary master. Unfortunately, it doesn't work with any BIND Version 4 secondaries (they'll receive the NOTIFY messages, but will not understand them). Active Directory-integration, described in Chapter 8, also avoids zone synchronization delays.

If you decide to configure your network with two (or more) tiers of secondary servers, be careful to avoid updating loops. If we configured wormhole to update from diehard and then accidentally configured diehard to update from wormhole, neither would ever get data from the primary master. They would merely check their out-of-date serial numbers against each other and perpetually decide that they were both up-to-date.

9.2.3 Caching-Only Servers

Creating caching-only name servers is another alternative when you need more servers. Caching-only name servers are name servers not authoritative for any zones (except for the automatically created reverse-mapping zones). The name doesn't imply that primary master and secondary name servers don't cache—they do—but rather that the only function this server performs is looking up data and caching it. As with primary master and secondary name servers, a caching-only name server needs a cache.dns file and the automatically created zones, 0.in-addr.arpa, 127.in-addr.arpa, and 255.in-addr.arpa. The configuration of a caching-only server looks like Figure 9-4.

Figure 9-4. The DNS console showing a caching-only name server

A caching-only name server can look up domain names inside and outside your zone, as can primary master and secondary name servers. The difference is that when a caching-only name server initially looks up a name within your zone, it ends up asking one of your zone's primary master or secondary name servers for the answer. A primary or secondary would answer the same question out of its authoritative data. Which primary or secondary does the caching-only server ask? As with name servers outside of your domain, it finds out which name servers serve your zone from one of the name servers for your parent zone. Is there any way to prime a caching-only name server's cache so it knows which hosts run primary and secondary name servers for your zone? No, there isn't. You can't use cache.dns—the cache.dns file is only for root name server hints.

A caching-only name server's real value comes after it builds up its cache. Each time it queries an authoritative name server and receives an answer, it caches the records in the answer. Over time, the cache grows to include the information most often requested by the resolvers querying the caching-only name server. And you avoid the overhead of zone transfers—a caching-only name server doesn't need to do them.

9.2.4 Partial-Secondary Servers

In between a caching-only name server and a secondary name server is another variation: a name server that is a secondary for only a few of the local zones. We call this a partial-secondary name server (although probably nobody else does). Suppose movie.edu had 20/24-sized (the old Class C) networks (and a corresponding 20 in-addr.arpa zones). Instead of creating a secondary server for all 21 zones (all the in-addr.arpa subdomains plus movie.edu), we could create a partial-secondary server for movie.edu and only those in-addr.arpa zones the host itself is in. If the host had two network interfaces, its name server would be a secondary for three zones: movie.edu and the two in-addr.arpa zones.

Let's say we scare up the hardware for another name server. We'll call the new host zardoz.movie.edu, with IP addresses 192.249.249.9 and 192.253.253.9. We'll create a partial-secondary name server on zardoz, with the configuration shown in Figure 9-5.

Figure 9-5. The DNS console showing a partial-secondary server

This server is a secondary for movie.edu and only 2 of the 20 in-addr.arpa zones. A "full" secondary would have 20 different zones (plus the three automatically created) under Reverse Lookup Zones.

What's so useful about a partial-secondary name server? They're not much work to administer because their configuration doesn't change much. On a server authoritative for all the in-addr.arpa zones, we'd need to add and delete in-addr.arpa zones as our network changed. That can be a surprising amount of work on a large network.

A partial secondary can still answer most of the queries it receives, though. Most of these queries are for data in movie.edu and the two in-addr.arpa zones. Why? Because most of the hosts querying the name server are on the two networks to which it's connected, 192.249.249/24 and 192.253.253/24. And those hosts probably communicate primarily with other hosts on their own network. This generates queries for data within the in-addr.arpa zone that corresponds to the local network.