Web Development

Set up split-brain DNS with Active Directory integrated zones

Derek Schauland explains how to configure conditional forwarding in Windows Server 2003 when a split-brain DNS set up is called for.

Many organizations may make use of two or more DNS servers -- one for internal users and one for the rest of the world via the Internet. In addition, these organizations also use Active Directory integrated DNS to allow for easier management. In some cases it may be necessary to forward requests sent to these DNS servers differently, based on the location of the requester; this is what's known as split-brain DNS usage. This concept came about because some requests need to be forwarded differently if they go to the internal DNS server versus the request that would go to the publicly available DNS server, and Windows Server 2003 can handle this DNS behavior.

Let's look at split-brain DNS in Windows 2003 using Active Directory integrated DNS.

When does split-brain syndrome occur?

Organizations that have multiple internal domain names such as sales.company.com and research.company.com can run into a problem with split-brain DNS because each domain requires DNS to work properly with Active Directory. If I'm a user in research.company.com domain and I need to find a Web address or a computer at sales.company.com, there may be an issue when my DNS server tries to forward this request. The request goes to the DNS server for my domain, and the domain then passes it off to the public DNS servers for my company; when this happens, the DNS resource I'm looking for needs to be on the Internet for the server to find it. Because the resource I'm looking for is in a different internal domain, then there's no chance of the external DNS server finding it in a typical DNS scenario.

Windows server 2003 can combat this issue by using conditional forwarding. Conditional forwarding specifies that certain requests should not be forwarded to public servers, but instead forwarded directly to a specific server within your environment. This way, if I'm in the research.company.com domain and I need to get to a resource in the sales.company.com domain, when the DNS request gets to my domain's DNS server, it can be sent directly to the other domain's DNS server. To the user, this is a seamless process that directs them to the correct resource.

How is conditional forwarding configured?

To configure conditional forwarding as an attribute of DNS, complete the following steps:

  1. On a Windows Server 2003 domain controller, open the DNS console.
  2. Right-click the DNS server you wish to work with and click Properties.
  3. Select the Forwarders tab of the DNS properties dialog box for the selected server.
  4. Click the New button to the right of the DNS domain list.
  5. Enter the domain name for which the conditional forwarders should be configured -- for example, sales.company.com -- and click OK.
  6. Click on the new domain forward that you just added in DNS domains list and type the IP address of the primary DNS server for that domain in the box below, labeled Selected Domains Forwarder IP Address List.
  7. Click the Add button.

Once you click OK on the DNS properties dialog box, the conditional forwarder for the domain you specified will be ready to go; however, you may want to restart the DNS service just to make sure everything is working. Note: For conditional forwarders to work, all the DNS servers in your Active Directory environment must run Windows Server 2003.

This simple change and setup can enable multiple subdomains to exist in your Active Directory environment.

Do you have other questions about Windows Server 2003 configuration?

About

Derek Schauland has been tinkering with Windows systems since 1997. He has supported Windows NT 4, worked phone support for an ISP, and is currently the IT Manager for a manufacturing company in Wisconsin.

14 comments
tejasv04
tejasv04

thank you. this is very useful for me

Photogenic Memory
Photogenic Memory

I had no idea DNS configuration were this frustrating and complex. The article itself is simplistic in it's explanation and is a fine starter to understanding how to implement such a setup. But the responses to it; I'm so confused with. How are people setting up BIND to accomplish this? What do the named.conf config statements look like? What do the MS DNS server configs look like to talk to BIND? How do you test to see if things are working correctly besides dig and nslookup? What better guides are out there to clarify on the topic? Why does ADS need a different DNS refferal look-up and sync with related domain controllers whatever? I'm sorry for being frustrated. After reading this article and reading the responses; I feel like I'm in a house where everyone is speaking extra-fast and vague in a coded language. Can someone please take the time out to explain or post a link for a place to being understanding the topic better? I know what DNS is and BIND but I've never setup my own name-server in this manner.

Derek Schauland
Derek Schauland

If you are using Active Directory, would conditional forwarding of DNS requests be useful to your organization?

Freddy01
Freddy01

The reason why you may be confused between the replies, and the article, being that there's some flaws in the terms used in the article. As posted, the article doesn't actually deal with a split-brain scenario - nothing presented showed two sources of authority claiming to represent a domain. And it didn't describe how to deal with providing different answers from DNS, based on the source network of the enquiry. All it did was describe how to send enquiries to different nameservers based on the domain name requested. All it did do was describe how in a, perhaps poorly thought out internal DNS design, conditional forwarding could be used for sibling DNS domains to resolve each other, without forwarding to external nameservers. Conditional forwarding isn't the only way to achieve that. A better design from the outset would be better for the presented scenario - say a placeholder domain at the top of your internal DNS structure, and all other internal DNS domains being subdomains of the placeholder. For other situations where there's a fait accomplis, then true enough, conditional forwarding, stub-zones, secondary zones, can all be used for that scenario. But for split-brain scenarios, where, say, you have a domain namespace known internal and externally, to provide different answers to DNS enquiries, based on the source network of the enquiry, requires the use of views in BIND, because Microsoft DNS doesn't provide the functionality of views as of yet. As to how you'd do it in BIND, you'd need to be running reasonably current versions of BIND, use ACLs to define (say) your internal networks (in named.conf) and then use those ACLs to differentiate views within named.conf for separate sets of zone files for internal access and external access. As to how you'd do all this integrated with AD, I'd say that gets a whole deal more complex. I would really recommend that Microsoft DNS is used for AD domains that are truly active. You can use BIND, but it is more complex for that. Design matters, for those sorts of situations, though. So designing a placeholder domain (both AD and DNS) at the top of your internal namespace. Now you could use BIND at that level (ie be authoritative for the parent placeholder namespace), and delegate the _ (underscore) Microsoft DNS zones (that get dynamic updates, to AD integrated DNS zones in the parent placeholder domain. So whilst Microsoft DNS wouldn't be fully authoritative for the placeholder / parent domain, it would be for all the things that really benefit from dynamic updates (not that BIND can't deal with that, it's just that authentication is more complex using BIND). After that, the placeholder BIND implementation at the parent / placeholder domain can deal with any split-brain scenarios, using views. Then all the AD domains and namespaces can be delegated to Microsoft DNS servers in the child domains. That's a bit of a whistle-stop to how it could be done, but it's my off-the-cuff response to what you've asked.

scarville
scarville

BIND does what you describe easily. I use AD for MS systems and BIND for DNS. AD just updates the DNS servers via IXFR. Any zone that has a different address for different part of the network has internal and external views on the DNS server.

Freddy01
Freddy01

Split-brain DNS is more likely to be when you have two (or more) ideal results from DNS based on where the request comes from. Conditional forwarding doesn't achieve that. What it does do is allow you to redirect / forward, to differing nameservers based on the domain requested - previously forwarding was all or nothing, to one set of forwarders. Dealing with split-brain DNS enquiries is something that's more likely dealt with using views in BIND. Whereby you can actually use conditional logic on the location that the enquiry comes from, to decide on the answer received. Conditional forwarding doesn't do that, though, because the condition bit of the conditional isn't based on where the enquiry originated from, it's based on the domain enquired about.

Photogenic Memory
Photogenic Memory

I get it. I really get it now! Since MS ADS services can't or are unable to do what BIND does; it always refers to a "true nameserver" in the form is sub or child domain. Internal the MS domain will manage itself while asking for outside DNS info; it'll refer to the true nameserver. The design you describe seems so much more simple then the split-brain scenario. I guess to help ADS services replicate outside the domain/LAN; you could use routing and remote access to communicate as well. Thank you so much. I've never set any of this stuff up but after reading your response; I'm going to give it a try somehow. Thank you.

sjdorst
sjdorst

We're a very small company and have only 5-6 names that need resolution from the outside world. Internally, AD integrated DNS works well for us. Quite simply, it's far easier to use a public service (easyDNS) for our External nameserver than it would be for me to run BIND in order to get views. If we were larger, with more time budgeted for this kind of computing infrastructure stuff, I probably would use BIND.

Derek Schauland
Derek Schauland

The way I see it Split brain and Conditional forwarding are quite similar. However I am not a Bind user. Split brain as I understand it is a request that your local DNS server cannot find the server within its domain because it lives in a second domain within your organization. Once the record is passed to the external or Internet DNS servers the request will not get to the domain containing the server. Conditional formatting can address this issue for Windows Integrated DNS zones by allowing requests for specified servers to be sent to defined DNS servers within the correct domain. I am not sure how this does not address the issue for Windows users? Perhaps there are different definitions of "Split Brain" DNS?

sjdorst
sjdorst

Windows 2003 DNS can easily handle multiple domains without need selective forwarding. The "split" problem that more frequently needs solving is internal IP vs external IP. I'd like to have my DNS work for both queries from inside our firewall (returning the internal IP address) and queries from the rest of the world, coming through our firewall. These answeres are different depending on the source of the inquiry, not the domain requested

Freddy01
Freddy01

It's quite a normal and sane thing to use an external, managed provider for external presented names - and one that is valid for bigger installations, too. Views can be useful in other scenarios, in larger internal networks, where there's DMZ and NAT being used - I've seen instances with DNS requirements, that's invovled split-brain scenarios in purely internal network scenarios. It should always be a horses-for-courses approach with the type of DNS implementation. Views are the only real answer for dealing with split-brain within one DNS environment - but as feature rich as BIND is, it's not the panacea for all DNS requirements. AD and Microsoft DNS integrates tightly, and works well together - there's no sense in bucking that trend, if there's a better fit.

Derek Schauland
Derek Schauland

Thanks for the feedback. It is appreciated. I suppose going after conditional forwarding would have been the best approach and not worrying about the other, the research I started doing to prep seemed to put them together... so that is where I went.

Freddy01
Freddy01

"Split brain as I understand it is a request that your local DNS server cannot find the server within its domain because it lives in a second domain within your organization." That's not split-brain. Split-brain is where two entities believe they have authoritive data or access for a resource. For example, say your company has a domain called aceco.com, and is known externally on the internet as that domain name; but also uses that namespace internally. Perhaps they use an external provider to provide and manage their internet exposed DNS domain aceco.com (like somebody has mentioned in this thread). So on the internet, there's nameservers claiming authority for aceco.com., and internally, the companies DNS servers on their LAN claim authority for aceco.com. That's split-brain, because there's two sources of authority, for the same domain - and quite likely containing different data. Now if you were to do that all internally, you'd either have to mirror what an external DNS provider would do (ie use DNS servers solely serving the externally exposed part of the domain name), that may well present some challenges, though, for comprehensive internal resolution - or use views in BIND. The reason why your understanding of split-brain, isn't actually split-brain, being that in your scenario, there's no two (or more) entities claiming authority for the same data / domain. It's merely poor design, for that situation. Better design from the outset, leveraging placeholder domains and hierarchical namespaces normally means that such scenarios shouldn't be a problem. And conditional forwarding is no panacea or far from the only solution, there, for (in effect) side-ways lookups of domain enquiries. Stub zones, secondary zones are all useful alternatives, if you're presented with a situation that forces sideways lookups before forwarding externally. They each have their pros and cons, and suitablities, depending on requirements, and logical environments. Your article was a bit confusing and misleading, because you did start talking about split-brain - and even mentioned dealing with enquiries differently, due to their source network - but your presented solution never went to address that. All it did address was forwarding, conditionally, based on requested domain name - which true enough, could be dealt with by conditional forwarding, stub zones, or secondary zones. I would have thought it better to advocate better design, though, and plan ahead of time with your internal namespace to try and remove the need for such sticking-plasters, by using more hierarchy in internal namespaces, and the use of placeholder domains internally, so the need for breaking hierarchy shouldn't occur.

Freddy01
Freddy01

I think the only likely answer to your needs is to use views within BIND, I don't think that functionality is yet in Microsoft DNS. That way you can define ACLs within the BIND configuration, say, grouping your internal networks, then providing a "view" of DNS zones. When BIND gets a DNS enquiry that it's authoritative for, if origin of the enquiry is on an internal network, BIND uses the zone data for the "internal" view. All the answers you are happy to supply to external networks, that are either different, or perhaps a small subset of the full DNS picture of your internal network you'd define as being an "external" set of zone data. You can use reasonably complex logic in the definition and grouping of the networks, that you use for this logic (which is actually truly based on the origin of the enquiry). BTW, I'm not responding to this as somebody who's anti-Microsoft - far from it - I manage DNS on several platforms, using both Microsoft DNS and BIND, I'm just contributing accuracy on the subject. For the original article writer, split-brain normally refers to scenarios where two (or more) entities believe they have the authoritative view or control of data or resources. You started off talking about that, then went on solve a different problem and present a different solution.