Most companies these days have a public Internet domain name, such as www.Microsoft.com. When companies begin implementing Active Directory (AD), which requires a DNS name for the domain name, they have to make a decision: use a private domain name (such as Microsoft.pri) for the AD domain, or keep using the public name (Microsoft.com) for both AD and public use.
The benefit of using a private domain name is that your domain is safer from harm. You have two domains, a public one and a private one. The downside is that users might think it's weird. For example, in AD, users can log on using their fully qualified user name; firstname.lastname@example.org, for example. That's easy for users because it looks like their email address. However, if you select a private domain name, users will receive email at email@example.com, but they'll log on with firstname.lastname@example.org, which is confusing.
So-called split brain DNS offers an elegant solution that combines the benefits of a private domain name with the benefits of a public domain name—with almost none of the downsides of either.
Figure 23.1 shows how split DNS can be configured so that both your internal and public domains use the same domain name, company.com.
Figure 23.1: An example split DNS configuration.
In this example, you have two DNS servers: one on your internal network, and one that's accessible to the public (you'd likely have at least two in each location, but that's not relevant to the basic configuration). Both DNS servers believe they're authoritative for your domain, meaning that they are the final source for all records related to the domain.
Your public domain record lists your public DNS server(s), meaning that the top-level domain (TLD) domain name servers will also list your public DNS server(s). When Internet users attempt to look up any host in your domain, such as www.company.com, they'll use your public DNS server. That server is configured with static records, including any Web servers, mail servers, and other publicly accessible servers.
Internally, your client computers are configured to use your internal DNS server. It might have dynamic DNS configured and believe it is authoritative for company.com. It might also be configured to forward requests to your ISP's DNS server so that your client computers can access Internet Web servers. Hence, the trick—because your Web server isn't connected to your internal DNS server, it won't be able to dynamically register its name. Thus, your internal DNS server won't contain a record for, say, www.company.com.
No problem, right? Isn't that what forwarding solves? Wrong. Because your internal DNS server is authoritative for company.com, it will never forward requests for anything involving company.com. "If I don't have it, nobody else will" is your DNS server's motto in this case. So you will need to create static records for all publicly accessible servers in the company.com domain. Doing so will permit internal users to access these external assets.
Split-brain DNS only has a couple of minor drawbacks. Primarily, you'll need to manually keep both DNS servers up to date with your publicly accessible resources. Technically, the public DNS server could use dynamic DNS, but the security implications of doing so aren't worth the convenience.
You can't perform zone transfers between the servers because they're both hosting a primary zone for company.com, and they can only transfer to another secondary zone of the same name. You wouldn't necessarily configure them as forwarders to one another, either; remember, authoritative servers never forward requests for their own domains.
In the previous example, the external resources were hosted on a different network. So what if you host your own Web servers? The picture looks remarkably similar, as Figure 23.2 shows.
Figure 23.3: Split DNS in a single location.
In this example, a DMZ or perimeter network contains the publicly accessible resources, including the Web server and the public DNS server. The internal LAN contains the internal resources. Close physical proximity or network connectivity doesn't matter for split DNS; the two DNS servers never talk to one another, and each is unaware that the other even exists.