Split-Brain DNS

The Domain Name System (DNS) is one of the most critical aspects of any IT environment. All Internet users, whether they know it or not, are dependent on DNS. If, like most Windows IT Pro readers, you’re running Active Directory (AD) in your environment, you know that your users are also heavily dependent on DNS to locate resources on your network, such as domain controllers (DCs). Without using DNS to locate a DC, your users wouldn’t even be able to log on!

Split-brain DNS is a configuration method that enables proper resolution of names (e.g., example.com) from both inside and outside of your local network. Although “split-brain DNS” sounds like something that would require an Ace bandage and a boatload of aspirin, it’s actually something that almost every organization uses. Despite how common it is, I still regularly hear from administrators who aren’t familiar with it for one reason or another, and who have problems that can be solved easily by setting up split-brain DNS. Let’s take a look at a situation where split-brain DNS is called for, then I’ll demonstrate how you can set up split-brain DNS in your organization.

A Splitting Headache
Imagine this frustrating scenario: You’re an administrator for a small organization, and you’ve just finished setting up a new web server. This new server is joined to your AD domain, mydomain.local, and you’ve securely published it to the Internet through your firewall. The machine name of this server is WEB01, making its Fully Qualified Domain Name (FQDN) web01.mydomain.local. You’ve assigned it a static IP address of 192.168.123.10.

Your ISP hosts your external DNS records, so you select an unused public IP address from the pool they’ve assigned to you, then ask the ISP to configure an A record for www.mydomain.com that resolves to your chosen public IP address. Later, sitting at your office desk, you type www.mydomain.com into the address bar of your browser, but your site doesn’t load. You confirm with your ISP that they’ve set up the A record correctly. You then call your neighbor, who’s home on vacation, and have her try to load your site. It works perfectly for her. What gives?

If you’ve set up your AD DNS server to forward queries that it can’t authoritatively answer to another DNS sever that can—such as your ISP’s DNS servers—you’re probably thinking that your configuration should load the page successfully from your office browser. Your AD DNS server contains only the my domain.local zone, so a query for www .mydomain.com is forwarded to the ISP’s DNS servers, which should return the correct results to you. We know the ISP’s DNS servers have the correct information because your neighbor was able to access the website. However, the ISP’s server answers your query with the public IP address of your site.

“So?” you might be saying to yourself. “That should work: My computer should then connect to that IP address, and everything should be lovely!” But it isn’t. The problem is that your edge router or firewall is configured such that when it sees one of its connected networks trying to send information to itself, it drops the packets and you’re dead in the water because your site doesn’t load.

The solution is clear: You need to make your internal DNS servers answer queries for www.mydomain.com with the static IP address 192.168.123.10.

Split-brain DNS ensures that when users at the office on the local network type in www.mydomain.com, the DNS record returned contains the internal private IP address of the website you’ve set up, but when users away from the office’s local network try to access www.mydomain.com, the DNS record returned contains the external public IP address of the website. Figure 1 shows a highlevel overview of the query paths after this setup is complete.

Double-Duty DNS
Contrary to what you might believe, your AD DNS servers are capable of hosting DNS zones that aren’t also AD domains. In fact, these zones can be AD-integrated without being AD domains!

For this example, though, we’ll configure a new primary DNS zone on a Windows Server 2003 Standard Edition AD DNS server. Start by opening the Microsoft Management Console (MMC) DNS Management snap-in and expanding the server node. Right-click Forward Lookup Zones, then click New Zone to launch the New Zone Wizard. Click Next on the Welcome page to proceed to the second page of the wizard. As Figure 2 shows, you’ll see choices for creating a Primary zone, Secondary zone, or Stub zone, as well as a checkbox, selected by default, that lets you store your new zone in AD. Select Primary zone and clear the checkbox for storing the zone in AD; for this example, we want to store our zone in a flat file.

On the wizard’s next page, enter the zone name mydomain.com. When you click Next, you’ll be given the option to change the filename that the DNS server uses to store the zone records; for this example you can use the default that the wizard suggests. Figure 3 shows the wizard’s Dynamic Update page, where you’ll have two options: to let the zone accept both nonsecure and secure dynamic updates or to not allow the zone to accept any dynamic updates. We aren’t setting up any records that should be updated dynamically, so select Do not allow dynamic updates. The last page of the wizard presents a summary of what will occur after you click Finish.

Now if you expand Forward Lookup Zones, you’ll see an entry for mydomain .com. Right-click this entry and select New Host (A), and you’ll see a dialog box like the one Figure 4 shows. Following our web server example above, we’d enter www as the name and 192.168.123.10 as the IP address. Don’t select the Create associated pointer (PTR) record checkbox because we’re not interested in setting up a reverse DNS entry for this host; reverse DNS resolves IP addresses to names and we only need to resolve the name to the IP address. Click Add Host, and you’re done.

Continue on Page 2

   Previous  [1]  2  Next