Split dns windows server 2008

The Split DNS Architecture

Tip

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.

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. A basic diagram of this infrastructure is shown in Figure 4-26.

Картинка с сайта: www.oreilly.com

Figure 4-26. How split DNS architecture is laid out

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:

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:

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. I recommend Building Internet Firewalls, Second Edition (O’Reilly), by Zwicky et al., for detailed and thorough guidance on this topic. 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.

internal/external same dns name setup split dns for mail. and www. how to configure in DNS manager

August 21st, 2013 2:23am

August 22nd, 2013 1:09am

August 21st, 2015 2:42am