How can I use a Linux BIND DNS server for my Active Directory forest?

Question

I am trying to setup an Active Directory forest that uses a Linux BIND server for DNS. The goal is that the Domain Controller (DC) to be able to make entries in the /etc/bind/db.foresta.net file from the linux server.

Here is a diagram with my current setup and specs:

WinServer DC: dc.ntds.foresta.net Linux DNS: sysdns.foresta.net

My current Linux server configuration: http://pastebin.com/nz5GQcGY

On the DC I have setup a new AD forest and in the IP configurations I have set the IP of the linux server as DNS. But now the problem is that I don't see any new entries in the file that I described above (db.foresta.net) and I don't know what further steps I need to take to make this work.

What works so far: In the Windows Server I can open up a browser and browse any website using that linux dns server.

Every feedback is appreciated.

Solution 1

The way I read your question is that you're trying to avoid having the AD domain controller host DNS at all. And that's a perfectly valid configuration.

You basically have two options.

1. Configure BIND to allow the DCs to perform dynamic updates
2. Manually populate the DCs' DNS entries into BIND after a DC is promoted

Option 1 is the most common. And the ways you can configure BIND for this range from simple IP whitelists to more complex TSIG setups. But once it's done, you're golden. There are plenty of guides out there on configuring BIND for DDNS. If you need specific help on this, you might want to create a separate question.

Option 2 is "easier" on the BIND config side, but a little more work when promoting a DC. There is a file that gets created on the DC after promotion that contains all of the BIND entries you need to add for that DC. %SYSTEMROOT%\system32\config\netlogon.dns All you really need to do is manually add those entries to your BIND server. However, you will also need to update those entries any time you make AD topology or FSMO role changes (add/remove a site, add/remove a domain, etc).

Solution 2

The two main strategies I've dealt with are delegation and forwarding.

With delegation, you configure BIND as a slave to the AD server, offloading the query load to the BIND server. As long as AD is still the SOA (ala ADI), then any dynamic updates will still be sent to the AD box. You can still configure other zones on the BIND server, however you can run into some issues with multiple views that I've sorted out in the past by adding conditional forwarders to the AD boxes.

With forwarding, you configure your BIND server to forward requests to the AD boxes, allowing you to point your clients at the BIND boxes so they can do the fetching and caching for non-AD requests, but this does very little to offload any of the client load from the AD boxes.

It rather depends on what your goals and resources are as to what is better for your environment. What is very important is maintaining a single source-of-truth for the zone. This is more difficult when running BIND in front of ADI zones due to how the various AD boxes keep their SOA records and serial numbers but if you're only running one ADC, then it's not even a concern.