8.2 Adding More Name Servers
8.2 Adding More Name Servers When you need to create new name servers for your domain, the simplest recourse is to add slaves. You already know howwe went over it in Chapter 4and once you've set up one slave, cloning it is a piece of cake. But you can run into trouble if you add slaves indiscriminately. If you run a large number of slave servers for a zone, the primary master name server can take quite a beating just keeping up with the slaves' 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:
8.2.1 Active Directory IntegrationWe discuss this new feature for Windows 2000 in Chapter 11. Briefly, this feature eliminates the load on the primary master from slaves' polling by eliminating the slaves! Remember that the main purpose of the primary master/slave 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 2000 stores all kinds of information about the network in Active Directory and replicates this information, too. With Windows 2000, you have the option of storing the definitive version of your zones' data in Active Directory rather than in zone data files on the primary master. All authoritative name servers load the zone data stored in Active Directory, which also takes care of replicating changes to the data. See Chapter 11 for more details and instructions on setting up this new feature. 8.2.2 Slave ServersYou can have some of your slaves load zone data from other slave name servers instead of from a primary name server. The slave name server can't tell if it's loading from a primary or another slave. 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 slave's configuration, you simply specify the IP address of another slave. 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 slaves. Remember that the refresh interval is the period after which the slave servers check to make sure that their zone data is still current. Therefore, it can take the first-level slave 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 slave servers the entire refresh interval to get a new copy of the zone from the first-level slave servers. The propagation time from the primary master server to all the slave servers can therefore be twice the refresh interval. Fortunately, using the DNS NOTIFY feature, which we'll describe in Chapter 10, avoids this delay. This feature is on by default and will trigger zone transfers soon after the zone is updated on the primary master. Unfortunately, it doesn't work with any BIND Version 4 slaves (they'll receive the NOTIFY messages but will not understand them). Active Directory integration, described in Chapter 11, also avoids zone synchronization delays. If you decide to configure your network with two (or more) tiers of slave 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. 8.2.3 Caching-Only ServersCreating 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 0.0.127.in-addr.arpa ). The name doesn't imply that primary master and slave name servers don't cachethey dobut rather that the only function this server performs is looking up data and caching it. As with primary master and slave 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 8-4. Figure 8-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 slave 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 the primary master or slave name servers in your zone for the answer. A primary or slave would answer the same question out of its authoritative data. Which primary or slave 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 slave 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 will grow to include the information most often requested by the resolvers querying the caching-only name server. And you avoid the overhead of zone transfersa caching-only name server doesn't need to do them. 8.2.4 Partial-Slave ServersIn between a caching-only name server and a slave name server is another variation: a name server that is a slave for only a few of the local zones. We call this a partial-slave 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 slave server for all 21 zones (all the in-addr.arpa subdomains plus movie.edu ), we could create a partial-slave 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 slave 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-slave name server on zardoz , with the configuration shown in Figure 8-5. Figure 8-5. The DNS console on a partial-slave server This server is a slave for movie.edu and only 2 of the 20 in-addr.arpa zones. A "full" slave would have 21 different zone statements in named.conf . What's so useful about a partial-slave 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 slave can still answer most of the queries it receives, though. Most of these queries will be 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.  |
| | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 154