SQL Server Magazine

Blueprint for High-Availability DNS Servers
You can build a high-availability DNS system in much the same way that you build a highly available file server, except that the quantity of data is typically much smaller. Your primary concern is typically not the time necessary to restore the data but rather the availability of the DNS server. Therefore, you probably don't need to worry about a solution that decreases a DNS server's restore time. Your architecture must ensure that a client requesting name resolution can always find a DNS server that contains your zone data. The most complex high-availability DNS solution you need is simply two or three servers that have complete copies of all the host records you want to publish.

When an Internet client needs to find the IP address of a server in your domain, it issues a DNS query, which starts a series of events that culminate in a DNS server sending a query on the client's behalf to your DNS server. For example, InterNIC's records for my company show that we're running four DNS servers. If a client enters the http://www.usi.net URL in a browser, a DNS query eventually arrives at one of our four DNS servers, which replies with the address of our Web server. If you register multiple DNS server addresses with InterNIC, DNS clients can address queries to any of your DNS servers, and if one of your DNS servers is unavailable, the clients can query the other servers. The result is that the client perceives continuous service, even if one of the DNS servers is down. For comparison purposes, at press time, Cisco Systems has registered two DNS servers, IBM has registered four, and Microsoft has registered six.

To create redundant DNS servers, you install the DNS service on two or more servers. On one of those servers, you use DNS Manager to add the domain's host information. On each of the other DNS servers, you use DNS Manager to specify that the server is a secondary DNS server for the domain and that it should copy the host data from the primary DNS server. DNS takes care of the initial data replication from the primary server to the secondary servers, as well as any subsequent replication of updates if the data on the primary server changes. In a Win2K environment, you can specify that the DNS data reside in Active Directory (AD), in which case AD replication takes care of the DNS transfers and you don't need to specify primary and secondary DNS servers. In addition to increasing the number of secondary DNS servers for fault tolerance, you can create intermediary DNS servers that simply cache responses from your DNS servers without holding a copy of the DNS database. These caching servers reduce the load on your primary and secondary DNS servers by reducing the number of queries that ultimately reach those servers. Your DNS records might be cached in any number of other DNS servers on the Internet, increasing the resolving capacity of your system at no cost. (Some people refer to this phenomenon as a scale away strategy.)

Assemble the Building Blocks
You need to determine how much availability you truly need, as well as which components you can combine to produce your chosen level of availability. I focused this discussion on blueprints for building simple high-availability systems on Win2K systems. Although more complex applications—such as Microsoft Exchange 2000 Server and Microsoft SQL Server 2000—require more sophisticated configurations, you can still use many of the same building blocks I have provided in this article. (For detailed information about these building blocks, see "Related Articles in Previous Issues.")

End of Article

Prev. page     1 2 3 4 [5]     next page -->