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.
However, the local DNS server will eventually return to CNN.com's DNS server to determine whether http://www.cnn.com's IP address has changed. The reason for the return trip is that when the CNN.com DNS server responded to the initial query, the response included not only http://www.cnn.com's IP address but also the amount of time that the local DNS server should cache that IP address. That amount of time is called the Time to Live (TTL). All responses to DNS resolution requests contain a TTL. After the TTL expires, a new query causes the local DNS server to return to the Internet to resolve the name.
Centralizing Cache with Forwarders
You can see that caching DNS resolutions is a great idea. If CNN.com's TTL were 2 days long, a local caching-only DNS server could resolve http://www.cnn.com for 2 days before having to recontact CNN.com's DNS server.
Now, consider the effects of adding a second local caching-only DNS server—let's call the first local DNS server DNS1 and the second server DNS2. When DNS1 learns something, it doesn't share that information with DNS2. For example, if someone were to ask DNS2 for http://www.cnn.com's IP address, DNS2 must get the information from CNN.com's DNS server even if DNS1 has cached that IP address. In other words, DNS1 and DNS2 don't share a cache.
But if you use a forwarder, servers can share a cache. The idea with a forwarder is this: You set up some local caching-only DNS servers as usual to serve the name-resolution needs of workstations and other servers. Then, you set up another server that acts as a sort of DNS server for these DNS servers. In DNS terms, this server is a forwarder.
When one of the local caching-only DNS servers gets a request to resolve a name that it doesn't already have in its cache, that DNS server doesn't go to the Internet to resolve the name; instead, the server asks the forwarder to resolve the name. If the forwarder—which is on the same LAN as the local caching-only DNS server and can communicate with that server at high speeds—knows the answer, the forwarder can quickly answer the local caching DNS server's question. If the forwarder doesn't know the answer, the forwarder obtains the answer from the Internet.
Suppose DNS1 serves the first person to ask for the IP address for http://www.cnn.com. Because DNS1 doesn't know the answer, it asks the forwarder. The forwarder doesn't know, either, because no one has asked the question before, so the forwarder goes to the Internet for the answer. After the forwarder finds http://www.cnn.com's IP address, it caches the address, then sends that information to DNS1.
Now, suppose the second person who wants the IP address for http://www.cnn.com is connected to DNS2. DNS2 can't resolve the address from its cache, so DNS2 asks the forwarder. This time, the forwarder knows http://www.cnn.com's IP address and satisfies DNS2's request at LAN speed.
To tell a Win2K DNS server to use another DNS server as a forwarder, simply open the Microsoft Management Console (MMC) DNS snap-in and right-click the icon that represents the DNS server that you want to act as a forwarder. Choose Properties, and you'll see a Forwarders tab, which Figure 1 shows. The Forwarders tab lets you specify one or more forwarders and a timeout value.
Why would you want a timeout value? Well, if your forwarder stops working, DNS1 and DNS2 won't be able to get the answers to new name-resolution questions. DNS handles that eventuality with a timeout. If a local caching DNS server such as DNS1 or DNS2 asks the forwarder a question and the forwarder doesn't respond within a certain length of time, the local caching DNS server goes to the Internet and resolves the name on its own. (As I explain later, that action is a potential liability.)
Using Split-Brain DNS
Take a look at a DNS zone in an AD domain, and you'll notice two things. First, AD stores a lot of stuff in DNS. Second, much of that stuff is information that you wouldn't want anyone outside the organization to see. In particular, a zone in an AD domain contains the names and addresses of your DCs, and you probably don't want the world to have that information.
One way to avoid running a too-visible network is to keep two sets of DNS books: one DNS zone that the outside world can see and another DNS zone that only the internal organization can see. Some people call this arrangement split-brain DNS. Here's how it works.
When you ask your preferred DNS server to resolve a name for you, the server first looks in its cache. Then, if the name isn't in the cache and the DNS server holds any zones, it looks in those zones to try to resolve your request. The server goes to a forwarder or to the Internet only if it can't answer the request from its cache or its zones. The key to split-brain DNS is that the DNS server favors the information in its zones over information it can find on the Internet.
Let's look at an example to see how to set up these two sets of books. Suppose we have a domain named acme.com. On that domain, we have a few DNS addresses that we want the outside world to be able to see—two DNS servers (ns1.acme.com and ns2.acme.com), a mail server (mail.acme.com), and a Web server (www.acme.com). Our externally visible acme.com zone, then, is slim—fewer than a dozen records, all of which refer to routable IP addresses accessible through the public Internet. We create that zone file and put it on our two externally visible DNS servers, ns1.acme.com and ns2.acme.com. (We might not even run our own DNS servers—for a zone that small, many firms simply let their ISP host the files.) Network Solutions has the addresses of ns1.acme.com and ns2.acme.com in its database of all DNS servers, and any DNS server outside of Acme—the kind that a user on the Internet might query—will need to ask Network Solutions' DNS servers where to find the acme.com servers. Consequently, the only servers that outsiders will see are ns1 .acme.com and ns2.acme.com.
Inside Acme, however, we have an intranet built on nonroutable addresses—perhaps a 10.x.x.x network—that uses some kind of port address translation scheme to connect to the Internet. Anyone inside Acme can initiate communication to the Internet, but people on the Internet can't initiate communication to our internal 10.x.x.x addresses. (To keep this example simple, the port address translation is the only "firewall" that we'll imagine for Acme.)
On the intranet, we set up a group of DNS servers that act as preferred DNS servers for other machines on the intranet. Those DNS servers use the external acme.com DNS servers as forwarders, enabling people within the intranet to resolve names and surf the Internet. The internal DNS servers aren't simply caching-only DNS servers; those internal servers also hold a copy of an acme.com zone. However, that zone isn't the externally visible acme.com zone that ns1 .acme.com and ns2.acme.com hold. Rather, the internal DNS servers hold an acme.com zone that AD and DDNS built. If that internally visible acme.com zone is an AD-integrated zone, then the internal DNS servers are Win2K DCs for the acme.com AD domain.
If you've never set up a split-brain DNS structure, you should take a minute to review and think about what's going on. None of the systems within the Acme intranet use the external DNS servers as their preferred DNS-name resolvers—rather, the machines on the intranet look to the intranet's DNS servers to resolve names. Those internal servers hold copies of a zone called acme.com. But the acme.com zone that the internal servers hold is different from the acme.com zone that the outside world sees (although the zone on the internal servers presumably contains the same records that the external servers' zone contains—records that point to the Web and perhaps to mail servers). Instead, the internal zone contains the information that Win2K systems need to locate DCs.
The outside world will never find or refer to those intranet DNS servers because Network Solutions' DNS servers don't know about Acme's intranet DNS servers. So, an attempt to resolve an acme.com name from the Internet never reaches an intranet DNS server. Even if a user from outside Acme were to attempt to use an internal DNS server, that attempt would fail because the internal server has a nonroutable IP address.
Using Slave Servers to Protect Intranet Servers
Before leaving the Acme example, I want to note a potential security problem. I said that the intranet DNS servers use the external DNS servers as forwarders. But recall what happens when a forwarder doesn't respond quickly enough to a name-resolution request—the intranet DNS server searches the Internet's DNS servers to try to find the answer. Security experts say that action results in a potentially troublesome hole in security. Simply put, your DNS server could end up connecting to a computer that's masquerading as a DNS server. That false DNS server could exploit the connection to your intranet DNS server to do various kinds of mischief.
To avoid this exposure, you can tell your intranet DNS servers that if the external DNS servers timeout without resolving a name, the intranet servers must not attempt to resolve the name on their own. To configure your internal servers, go to the Forwarders tab in the DNS MMC snap-in and select the Do not use recursion check box. You then have what Microsoft calls a slave server.
Fitting into an Existing DNS Structure
What if Acme already has a DNS structure in place—perhaps some non-Win2K computers run by people who've been managing the DNS structure for years without having to worry much about Win2K and NT? Those folks might not be happy about having AD put a lot of information in their zones. Or maybe Acme's existing DNS infrastructure doesn't support DDNS or Internet Engineering Task Force (IETF) Request for Comments (RFC) 2782 service resource records (SRV RRs), making the infrastructure unacceptable for AD. If you're faced with an AD-unfriendly infrastructure, what can you do?
The simplest answer is that you can create a subdomain. Instead of giving the AD domain the same name as the organization's top-level domain (TLD)—acme.com, for example—you can create a subdomain named something like win2k.acme.com or ds.acme.com, where ds stands for directory service. The benefit of this approach is that it doesn't affect the TLD's zone very much. Creating a child domain, such as ds.acme.com, in acme.com requires only a few records in the acme.com zone file: an NS and an A record for each DNS server in the subdomain. The NS record points to a Win2K system that acts as the DNS server for the ds.acme.com subdomain.
The bottom line is that AD requires a well-built DNS underpinning to work correctly. But the techniques of DNS design aren't complex; they're just new to most of us. If you use the points in this article to build your DNS structure, you'll be well on your way to a sturdy AD domain.
