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 machines service internal DNS requests and external DNS requests are serviced elsewhere, perhaps at a datacenter 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 to use split DNS to allow 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. 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 intends 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.

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.

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, as I covered earlier in this chapter. 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:

Comment an article   Name   E-mail    Title Available characters: 4000  Notify me of follow-up comments Enter what you see:

No comment posted