There have been a few instances in the last few years when people have gasped at my revelation that we run our Active Directory on a static BIND DNS infrastructure.  Nobody expects anyone to run Active Directory on BIND DNS – let alone a static one.  However, it is indeed possible to run such an environment and ours has been running for about a decade now.  I must admit it comes with its complications (more on that later) and significantly more work load but it can be done quite successfully, if that’s your requirement.

Reasons for using BIND are not technical at all.  Windows DNS has all the features BIND provides and there are some additional ones too which are ideal for a Windows environment.  Generally, there are political/practical reasons for doing it.  Sometimes the DNS team doesn’t want to let go of the technology they already know well and in others, it’s not considered practical to change the DNS infrastructure as part of a project, given it’s importance and the delay it’ll cause to the project.  Either way, I hope you’ll start your gradual move to Windows DNS, even if it means having a slave DNS environment just for your Windows estate.  Just choose a period when no major projects are running.

In the meantime, here’s how you do it.  It’s quite simple really!

  • Start with your first domain controller.  Before starting the DCPROMO process, check that the network settings have the server pointing to your normal DNS servers.  Run the DCPROMO process as usual.  In the DNS section, it’ll complain about not being able to update DNS.  It will also offer to install one on the server – don’t choose that option as it’s not required.  Actual message and steps will vary according to the Windows version you’re using but the concept is the same.  Go through the various screens afterwards and complete the DC promotion stage.
  • Once the promotion phase is complete – do not reboot! (it won’t hurt too much if you do – it’ll just waste time!)  Go to <SystemRoot>System32Config and take the “netlogon.dns” file from the directory.  This is the file that needs to become part of your DNS.  How you do it is up to you.  Some people would have a directory on the master DNS server with all of these collected from all domain controllers, to be merged into the master DNS map while others would just paste the contents into the main DNS map.  The main thing is the complete contents of this file need to go into the DNS.
  • Once the records are in DNS and replicated through the infrastructure, reboot the promoted domain controller.  Hopefully, it’ll be happy with the records upon boot.  The first domain controller is special in that by default, it’s also the Global Catalog (GC) so it will try to come up as a DC first and only once it’s successful in that task, go on to become a GC.  This might take a while so be patient.
  • Subsequent DCs become much easier as you promote them to become DCs first and only once these records are in DNS and everything is healthy, make that DC a GC.  Remember: You will need to “replace” the original contents of netlogon.dns of that DC in DNS with the contents of the new file.  It’s a complete replacement and yes, you’ll have to do this everytime a major change is made to the DC.  This is another reason why keeping all these files in a directory on the master DNS is quite useful.
  • Repeat the process as necessary for any subsequent DCs.

So, the next question is: Does this need any maintenance?  Unfortunately, quite a lot!  Here are the scenarios in which you’ll have to upload an updated netlogon.dns file to the DNS (there might be more but these are from the top of my head):

  • Everytime a FSMO role is moved (for all DCs in a domain),
  • With addition/removal of a domain (for all DCs in the forest),
  • With addition/removal of a site (for all DCs in the forest),
  • With addition/removal of a DC (for all DCs in a domain but for all in the forest if it was the last in site)

Also, don’t forget to remove the netlogon.dns “chunk” for a DCs from DNS when it’s decommissioned!  Forgetting to do so can have very undesirable effects – mainly on replication and performance!

OK, with this out-of-the-way, what are the “challenges” that you face when running Active Directory like this (in addition to the workload that you can see from above!):

  • As DNS is static, when the DC goes down for maintenance, it cannot inform DNS of its absense.  When a client does a look up in this state, the DC in question is listed as a valid domain controller.  Needless to say, the client suffers a delay while it tries to contact the absent DC.  The effect is quite visible in Outlook!
  • Moving a FSMO role which should take a few seconds, can take quite a while and for that reason, shortcuts are taken if just a reboot is required i.e. the role is not moved.  If the downtime is for a few minutes, you can generally get away with it but for a downtime longer than that, you should really move the roles.  Of course, that means two netlogon.dns updates – one while the DC is going down and one when it comes back and the roles are returned to it.
  • Zero-Touch deployment of desktops becomes difficult unless you take a decision to pre-populate DNS with their correct DNS names.  VDI makes it even more interesting!

These are just a few that I can mention from the top of my head but as long as you know the effects static DNS is going to have on your environment, you can develop processes to deal with the issues.  That said, given the amount of workload and user dissatisfaction  it generates, it’s best if the Windows estate is gradually migrated to a Windows-based DNS environment.

I hope this will reduce the pain for someone looking to deploy Active Directory with static BIND DNS infrastructure and also make them aware of some of the issues that come with it.  Alternatively, it could serve as a “deterrent” to anyone thinking about doing it this way 🙂  You never know – we might be the only one in the world with such a deployment.  If you are running your Active Directory on static DNS, I would love to hear from you!