I would like to try and move as much of our company DNS config into BIND, because I find it easier to work with, but having Active Directory means we have to have at least the domain's zone in Microsoft DNS.

Maybe I could have the domain's zone (e.g. company.local) in MSDNS, but have another zone in BIND (e.g. company.org) that has forward and reverse zones for the same computers. The DHCP server can assign BIND to be primary and secondary DNS, and we just use that zone for everyday use. We could also create slave zones for the domain zone in BIND, we just move all explicit DNS operation to BIND, but keep the domain zone available through BIND so that AD can function.

Has anyone done this and succeeded? Or is it an extraordinarily bad idea? :)

5 Answers 5


We do this. I'm not sure I would recommend it, but we do it:

Solaris server running BIND

  • runs authoritative for every forward domain except example.ad
  • runs authoritative for every in-addr.arpa zone except ones served by AD DHCP
  • pulls slave for example.ad and DHCP ranges from AD DNS servers

linux server running BIND

  • pulls slave for example.ad and DHCP ranges from AD DNS servers
  • pulls slave for everything else from solaris primary.

AD DNS Servers

  • runs master for example.ad
  • runs master for any in-addr.arpa zone served by AD DHCP.
  • forwards all recursive requests to the solaris/linux BIND installs

Windows Clients

  • Assigned the AD DNS servers by AD DHCP. We experimented with this and found that "the microsoft family of products" we used did not like not having the AD DNS server. We may have given up to early, but it didn't go well from what I remember.

UNIX/Linux/operational clients:

  • hard coded BIND DNS servers

In practice, here are some policies we've enacted:

  • any record that refers to IT-class services (exchange, etc) gets an A record in example.ad and gets a CNAME to record.example.ad in example.com
  • any record that refers to operational or network gear gets an A record in example.com and a CNAME in example.ad.

Our setup is actually even a little more complex than that because we purchased a company who uses Netware/AD for DNS/DHCP so we have a similar set of rules for them.

I'm not sure I would recommend doing this if your hand isn't forced. Our install is an attempt to make the best of a bad set of circumstances. However, I do have to admit that I like using BIND so much more than AD DNS, so, since we're clearly not going to get rid of AD, it's a nice way to have some use of BIND.

One problem we've had is caching in the AD DNS server. We've tried to educate our operational customers that their laptops use AD DNS, but changes are made in BIND, so if they make a change and they want to verify it they have to manually look it up against the correct servers. That's an annoyance, but it is an issue that comes up surprisingly often.

Hope that helps.

  • 1
    "We do this. I'm not sure I would recommend it, but we do it" - +1 for candour :)
    – user1804
    Jul 10, 2009 at 12:06

I've done this before, and I'll try to reconstruct from memory what I did.

The situation:

Win2K domain controller, various Windows desktops, AD environment. The DNS server would need restarting every few days because, well, it would just stop working.

The solution:

I had a Linux box on the network running a small intranet site, so I dropped BIND on that box. I set BIND up as a slave on the zone, and configured the Win2K box to send domain transfers to it. Then I configured the DHCP server on the Win2K box to supply the BIND box as the primary DNS server, and the Win2K box as the secondary DNS server. Now all updates to the DNS table on the Win2K box (including client boxes, as they were all DHCP) would get published to the BIND server, and everything worked great. Never had to restart the Win2K DNS server again.


The key issue is the Active Directory dynamic DNS updates that it does for the domain controllers' A records, PTR records, and the domain.com record itself ... plus, the underscored zones _msdcs.domain.com, _sites.domain.com, _tcp.domain.com, _udp.domain.com.

If your BIND version can support these dynamic updates, you could just use BIND.

If not, then you must use MS-DNS for the underscored zones, however you could manually code the A, PTR and domain.com record yourself and maintain it if/when you add/remove DC's. Make MS-DNS the authority for the underscored zones, and zone transfer/forward them to BIND so clients can find them.

Or, use a different domain entirely for AD (if you can) like corp.domain.com, host that entirely in MS-DNS and transfer/forward that to BIND.

Windows client machines also will want to dynamically create A/PTR records, so BIND itself must do that for them or allow them to do it, or again use MS-DNS for the whole zone.


We did exactly this at our old company:

company.com was the official domain that we maintained in BIND

company.net was the AD domain name - AD could do all it wanted in that zone and we wouldn't care

This kept things nicely separated for us and worked great.


Mixing Bind and MSDNS is fairly well documented, a quick search brought up http://support.microsoft.com/kb/255913, but there's probably more out there.

You have to decide what you care to have.. Previous company, I setup bind for everything except _{msdcs,sites,tcp,udp} and a subdomain where desktops lived so that they could do secure dynamic updates. It just works. (DHCP was on Unix.)

Mixing the two brings some extra work to keep things clean and up to date, but it's not the end of the world

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy