How can I get BIND and Microsoft DNS to work together well?
Solution 1:
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.
Solution 2:
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.
Solution 3:
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.
Solution 4:
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.
Solution 5:
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