Build the sturdy DNS underpinning that AD needs to work correctly
Active Directory (AD) is a nice bit of technology—particularly for a version 1.0 technology—that has grabbed many headlines in the Windows 2000related literature in the past couple of years. But to work correctly, AD needs its own directory: the directory of servers and workstations that you know as DNS. Before you start your AD planning, you need to do your DNS homework—or the best-planned AD will run badly.
Most of us learned the basics of DNS—DNS zones, Start of Authority (SOA), Name Server (NS), mail exchanger (MX), host (A) records, primary and secondary servers, and the like—under Windows NT 4.0, perhaps by setting up a simple DNS server. But to build a sturdy DNS structure that supports AD with style, you need to know more. For example, should you use the DNS server that ships with Win2K or a non-Microsoft DNS server, such as the almost ubiquitous BIND software that runs on so many UNIX and Linux boxes? Where should you put DNS forwarders and slaves—and more basically, what do those terms mean? What's split-brain DNS? And how can you make AD coexist with an existing DNS infrastructure?
Choosing a DNS Server
Don't assume that you'd be foolish to host your AD on a BIND (or Lucent Technologies' Lucent QIP or other third-party) DNS server. BIND is quite capable of working with AD—and has been since Win2K's inception.
To convince myself that AD and BIND get along, I spent a Saturday last year blowing up my existing three-domain AD forest and rebuilding it without using Microsoft DNS servers. Instead, I used MandrakeSoft's Linux-Mandrake 7.1 and the version of BIND available at the time. In addition to going smoothly, the process of building the AD forest seemed to go a bit faster than it did with a Win2K-based DNS server. I used the BIND-based DNS structure to support my AD for several months thereafter, and during that time I didn't hit a single snag.
I'm not implying that you shouldn't consider using Win2K's DNS server. That server offers an attractive, if nonstandard, option called AD-integrated zones. AD-integrated zones provide two things: multimaster primary zones and secure dynamic DNS (DDNS) updates. Win2K uses DDNS in the same way that NT 4.0 uses WINS: as a repository of computer names and IP addresses as well as a central directory of server types. When an NT 4.0 workstation wants to find a domain controller (DC) to help the workstation log on to an NT 4.0 domain, the workstation goes to WINS to find a DC. In contrast, a Win2K Professional workstation that's a member of an AD domain queries DDNS to find a DC. The DDNS server must then gather the names and roles of the machines in your domain. Win2K-based systems assist DDNS in that function by registering their names with a DDNS server. Thus, Win2K machines essentially introduce themselves to the DDNS server and augment its database of names and addresses.
But which DDNS server do Win2K-based systems introduce themselves to? In a standard DDNS system, such as a computer that's running either BIND or Win2K's DDNS server in primary zone mode rather than AD-integrated mode, only one DDNS server—the primary DDNS server—can accept registrations. Consider a worldwide enterprise that has thousands of machines around the globe seeking to reregister every morning: All those machines need to reregister with the same computer—the only computer that can accept those registrations. In contrast, an AD-integrated zone lets you designate any or all DCs to do double duty as primary DDNS servers and accept registrations. Machines can then register DNS names with local DCs, reducing WAN traffic.
However, registration is crucial only for servers and DCs. So, you could alternatively attack the registering-over-the-WAN problem by telling Win2K Pro boxes not to bother registering. (You make this change on the DNS tab of the TCP/IP Advanced Properties page.) Furthermore, DDNS differs from WINS in that DDNS registrations don't expire in a few days—by default, DDNS registrations stay in a DDNS zone forever. So, even if a machine can't reregister every morning, DDNS will contain a record for that machine, assuming that the machine registered at least once in the past.
AD-integrated zones have another feature that you might find attractive—secured DDNS registrations. If you use the default options to set up a DDNS zone on a BIND or Win2K DNS server, anyone who can connect to that server can register a machine in that zone. BIND lets you prevent registrations from machines outside certain subnets: When you list the subnets that the BIND server should accept registrations from, the server ignores all other machines. An AD-integrated zone lets you restrict DDNS registrations in a different way: You can require registering machines to log on to the AD domain before they register. This approach is a bit easier to set up than the BIND approach—simply click the General tab of a zone's Properties page, click the Allow dynamic updates? drop-down list, select Only secure updates, and you're finished.
Using Caching-Only Servers
Consider how you'll place DNS servers in your intranet to serve your users' needs. Many DNS servers exist to hold copies of an organization's zone files, as you've seen if you've ever set up a DNS server. But a lot of DNS servers hold no zones, living only to resolve names, whether on the Internet ("What is the IP address of http://www.microsoft.com?") or on your intranet ("Where is the nearest DC for acme.com?"). Such a DNS server is called a caching-only server. After you set up a zoneless DNS server, you can see a reference to its caching-only nature in the event log (event ID 708).
A caching-only server's strength lies, as its name implies, in the fact that DNS servers remember the results of previous resolutions. For example, if someone in your office points his or her Web browser to http://www.cnn.com, the Web browser asks its preferred local DNS server to find the IP address of http://www.cnn.com from CNN.com's DNS server. The preferred local DNS server goes out on the Internet to get that information, and that process takes time. But the second person to ask the local DNS server for http://www.cnn.com's IP address gets a nearly immediate response because the server resolves the name out of its cache rather than turning again to the Internet for the answer.
Prev. page
[1]
2
3
next page 
