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.