A DNS server is one of the most critical elements of a Windows 2000 network. DNS servers are used to resolve host names to IP addresses when browsing the Web, and Windows 2000 depends on a DNS server for Active Directory to work. Of course, when a network component is so critical to the overall functionality of your network, you want to make sure that you implement it properly. Here are a few tips on planning your organization’s DNS usage.
DNS and Windows 2000
You might wonder, if DNS has traditionally been used for Web browsing, why is implementing DNS services any different for Windows 2000 than it is for Windows 98 or Windows NT? Why not just let your ISP assign a DNS server or two for you to use and be done with it? Although you might be able to use your ISP’s DNS servers to service your Windows 2000 network, doing so isn’t usually in your best interest, because Active Directory is completely dependent on DNS services. Having at least one DNS server locally allows Active Directory to function without passing every single naming resolution request off to an Internet-based DNS server. Having DNS requests handled locally is a big plus when it comes to performance.
The fact is, you don’t have to use a Windows 2000 implementation of DNS. You can have all of your Windows 2000 servers using a Windows NT- or UNIX-based DNS server, and it won’t cause any problems as long as those DNS servers allow dynamic updates. In fact, the DNS server doesn’t even have to exist on your network. You can use a DNS server out on the Internet to get the job done, but performance may suffer as a result.
So why does Active Directory depend so heavily on DNS? To understand the answer to this question, consider that Windows 2000 is designed to be scalable and to be able to service a distributed organization. The obvious protocol of choice for servicing geographically spread out organizations is TCP/IP. Windows 2000 was designed to coexist with TCP/IP. When you create a domain in Windows 2000, you have to give the domain a DNS-style name, such as techrepublic.com. All other objects within the domain have names that build on the root DNS name.
This design makes it easy for Windows 2000-based machines to function in a distributed environment. For example, suppose a machine running Windows 2000 Professional needed to authenticate into a Windows 2000 domain. If the machine doesn’t already know the name of a domain controller, it could make an LDAP query to extract the name from Active Directory. Once the client has the name of a domain controller, it can pass that name to a DNS server, which can return the server’s IP address so the client can contact the server and begin the authentication process.
When planning your organization’s DNS implementation, the recommended method depends greatly on your organization’s physical configuration. The minimal requirement for Active Directory is to have one DNS server available, even if that server is not actually a part of your network. But let’s face facts: An off-site DNS server probably won’t be able to deliver the performance that your network requires to run smoothly, because DNS requests and the corresponding returned data would have to flow across your Internet link. This slow link would slow things down considerably versus the other option of having the servers located locally.
On the other hand, suppose you do have a local DNS server. A single DNS server probably isn’t going to be able to support an extremely large organization all by itself. For example, suppose you had 10,000 users and a single DNS server. There’s little doubt that the DNS server would be overwhelmed by the constant bombardment of requests, and performance would suffer tremendously.
Fortunately, most of us don’t have a 10,000-node network, but just for kicks, let’s look at the other extreme. Suppose that you had a 10-user network and a single DNS server. In such a situation, the DNS server would probably have no trouble keeping up with the demand. The problem with such an arrangement is fault tolerance. Suppose that the DNS server were to crash and go offline. While the DNS server was down, none of the other machines in the organization would be able to address each other by name once the entries in the local cache expire, because there’s no DNS server to resolve the host names to IP addresses.
An easy way to design your DNS environment
There are three basic issues that you need to consider when planning an efficient DNS environment:
- Server performance
- Fault tolerance
The easiest way to design an effective DNS strategy is to do so at the same time you design your Active Directory.
When you create a domain in an Active Directory environment, you have to give the domain a DNS-style name like techrepublic.com. It seems that these days, everyone is on the Internet, so when you create your first domain, you should register your domain name with the InterNIC. This allows you to make the domain Internet accessible. For example, if you were to register the name techrepublic.com, you could then create the Web site www.techrepublic.com. You could also place a mail server in the domain and have e-mail addresses such as Talainia@techrepublic.com. (This isn’t my real e-mail address, so no messages please.) You can register a domain name at Register.com.
So what does registering a domain name have to do with implementing a DNS strategy? Well, I explained how if a DNS server doesn’t have a database entry for a particular URL, the request is forwarded on to a higher-level database. At some point, a DNS server has to have an entry for your URL. However, maintaining the DNS entries that point to your Web site or mail server is your responsibility. Therefore, it should come as no surprise that when you register a domain name, the InterNIC requires you to provide the IP addresses of two DNS servers that you’ll be using to resolve your host name to IP addresses.
Since the InterNIC requires you to provide two DNS addresses for every domain name that you register, it may be no coincidence that Microsoft makes a similar recommendation. Microsoft recommends you have at least two local DNS servers for every domain in your organization. This recommendation takes care of the performance issue since two (or more) DNS servers share the workload. It also takes care of the fault tolerance issue since even in a crash situation, there will always be at least one DNS server running at any given time. Finally, this solution appears to take care of the bandwidth issue since it recommends using local DNS servers.
However, there’s more to the locality issue than meets the eye. Active Directory supports the use of sites, which allows a domain to span WAN links. Therefore, it’s possible that two or more offices that are geographically separated by great distances could theoretically be a part of the same domain. If you use sites, the recommended solution won’t work well without being expanded upon.
For example, suppose you have two offices separated by a WAN link. If both DNS servers are in one office, all DNS traffic from the other office will have to flow across the WAN link. Not only is this a slow process, but it also consumes bandwidth that could be used for other traffic. In such a situation, a better plan would be to place at least two DNS servers within each site.
Therefore, if you have a single domain made up of two sites, you’d want to have a total of four DNS servers, two at each site. Doing so provides performance and fault tolerance at the site level and prevents unnecessary DNS traffic from congesting the WAN link. Some DNS replication-related traffic will flow across the WAN link, but there’s really no getting around that, and that traffic is minimal compared to the amount of traffic that would be generated by client requests.
There are many different ways of implementing DNS services in a Windows 2000 environment. However, there’s no reason to make things needlessly complex. The best course of action is to plan the DNS implementation to best meet your organization’s needs.