Windows Server 2003 : Domain Name System - The Split DNS Architecture

Now that you have a good background on the special DNS techniques you can use, let's discuss a very common and fairly secure way to deploy DNS within your organization: using the split DNS architecture.

The split DNS architecture scenario consists of a set of internal nameservers that are used within the corporate computing environment in daily operations. There are also one or more nameservers facing externally to the Internet that outsiders use to connect to your corporation's electronic services, but that are separated from the internal nameservers for security purposes. Outsiders who query for information from your external nameservers won't be able to obtain information on your internal network structure and composition because the external nameserver is completely separate from the internal nameservers that hold this data. The external nameservers hold records only for externally facing

Figure 1. Setting up a conditionally forwarded DNS system

servers and not for your entire internal domain. This technique is called the split DNS architecture because DNS information is split between the inside and the outside of an organization.

Split DNS is a great way to deploy Active Directory-compatible DNS services within your organization, but it isn't the only way to deploy DNS.

1. Stub Zones

Now is the time to introduce a new type of zone, introduced in Windows Server 2003, called the stub zone. Stub zones contain only a subset of the information contained in a regular forward or reverse lookup zone. Specifically, a stub zone contains the SOA record, any pertinent NS records, and the A records for the nameservers that are authoritative for that zone, and nothing more. Stub zones are useful for creating split DNS infrastructures, where internal DNS requests are serviced by internal machines and external DNS requests are serviced elsewhere, perhaps at a data center or Internet service provider.

Now, how do stub zones and conditional forwarding play into the split DNS architecture? In a couple of ways: for one, you might do business with an organization that occasionally needs to access systems that reside within your corporate firewall, not outside of it. Because the external nameservers have no information on your internal systems, there's no default way using split DNS for outsiders to resolve canonical names within your firewall. To resolve this, you use stub zones, placed on the internal nameserver of the corporation with whom you're doing business, which again contain only NS and SOA records of your internal nameservers. That way, when people query for resources that you host, they go to their local nameservers, and their local nameservers see the stub zones placed there about your organization with the proper name and IP address for your nameservers. In essence, any organization that hosts a stub zone for your domain always will know the names and addresses of your nameservers. Best of all, regular zone transfers will make sure the information inside these stub zones is kept up to date, but of course you must have permission to conduct these zone transfers.

Conditional forwarding operates very similarly to stub zones, except that where stub zones simply contain information about a foreign domain's nameservers, conditional forwarding is used on the local nameserver to directly forward requests for information to the foreign nameserver. Unlike stub zones, conditional forwarders don't automatically update when information changes, so manual intervention is required if you need to change the addresses or names of the foreign nameserver; however, you don't need any special permissions on the foreign nameserver to use conditional forwarding because no zone transfers are involved. (I have not found that this process is scriptable, but this issue might be fixed in a future service pack or in Longhorn Server, due in 2007.) Some overhead is involved with conditional forwarding, however, if you have a large list of names to forward; the server has to check each and every request against this list, and if you have a large load on the server, this can slow down response time considerably for everyone hitting that particular server. For just a few zones, however, conditional forwarding can be the best solution, and it can be done without the foreign DNS hostmaster or administrator knowing or approving.

Both of these techniques are a major part of the split DNS architecture strategy. Let's take an example corporation—one that is intending to use Active Directory and is deploying DNS with that in mind—with a primary and secondary nameserver for the external side of the infrastructure and a second set of primary and secondary nameservers for the internal side. A basic diagram of this infrastructure is shown in Figure 2.

Note that the first set of primary and secondary nameservers is outside the corporate firewall, and they take care of any external requests that come for the domain. In fact, the registrar that has the corporation's domain registration lists these two nameservers as authoritative for that domain. However, the zone files on these servers are static—they list only a few, rarely changing items, which could be web, FTP, and mail servers. This is really all the public needs to know.

Figure 2. How split DNS architecture is laid out

There are two points to note about this portion of the scenario:

• The external nameservers are not authoritative for the internal, Active Directory-based DNS structure. They are authoritative only for external, Internet-based requests.

• If your ISP has been providing hosting for your nameservers, there's no reason it can't continue doing so. In fact, this is simpler to administer than hosting both sets of nameservers on your own premises.

Now let's focus on the internal nameservers for this corporation. The primary nameserver on the internal side is configured as the primary nameserver for the internal zone and is instructed to accept dynamic DNS updates from internal workstations and servers. However, these internal servers are blind (at this point) to the fact that outside the firewall, another set of nameservers is holding the same zone name with different records. In addition, the workstations within the business are configured to think of the authoritative nameservers for the domain as the internal servers; this is where they will register themselves via dynamic DNS, and also where they will first look to resolve Internet names.

So, how do internal users resolve names on the Internet if they can't see the external set of nameservers? It's easy—the internal primary and secondary nameservers are configured to forward Internet requests to the external primary nameserver. So, if the address being requested by the client isn't in the internal nameserver's cache (meaning it hasn't been requested recently by another client), it will ask the external nameserver for the answer. No zone transfers are involved—it's just straight forwarding. But how might external users resolve internal DNS names? The short answer is: they won't. That's a security feature. Because the external users know only about the external nameservers, and the external nameservers know only about themselves and not the internal nameservers, there's no way for the external nameservers to report any information about internal DNS records inside the firewall.

The only problem you might run into is when internal users attempt to access the company's own resources on the external side of the firewall; to allow this, simply add a static record to the internal nameservers that points to the correct external resource. You don't introduce any security problems that way because there's still no "window" for external users to see into your internal structure.

So, in essence, you have a DNS architecture "split" between internal and external nameservers. If you're looking to reproduce this architecture, the following summarizes the correct procedure:

1. Create two sets of servers—one for in front of the firewall, and one for behind it. Install the DNS service on both.

2. Make every nameserver point to itself for its own DNS information; you do this within the network card properties where you indicate the IP address. There's no need to configure a secondary nameserver for each of these.

3. Copy any external records your internal users might need to the internal zone. This includes web, mail, and FTP servers. Remember, if you don't do this, your users won't be able to resolve the names of anything outside the firewall.

4. Configure external forwarders—these are the machines to which your internal nameservers will forward requests so that your internal users can resolve Internet names.

5. Slave the internal set of nameservers to these external forwarders you created in the previous step. This shields them from the Internet's blinding eye.

6. Configure all machines on the internal network to use only the internal nameservers. This allows them to register with Active Directory if appropriate and to find internal resources, which they couldn't find if directed to the external nameservers outside the firewall.

2. Security Considerations

Split DNS architecture is implemented with security in mind, but you can always take more steps to harden those DNS systems. You've already taken two steps in this process: for one, slaving the internal nameservers to the external forwarders eliminates the possibility that if the firewall of some other transmission problem prevents the external forwarder from responding, the internal nameserver will conduct its own search of the Internet. You obviously don't want your internal nameservers touching anything on the outside of the firewall except those external forwarders.

The other step is the use of the firewall to separate the two sets of nameservers from each other. You need to ensure that the firewall that protects the perimeter of your corporate network from the Internet is configured correctly and locked down as tightly as possible. You'll especially want to ensure that only a few ports, such as the DNS port, 53, are open.

Other than that, this architecture is fairly secure right after implementation.