Purpose
A few years ago I had a customer that lost their DNS databases that were stored in AD. They asked me if there was any way to recover this data without performing an authoritative restore. That got me thinking of what we could use native to DNS that could provide backups and restores that would be affected by Active Directory as little as possible. I was able to come up with a solution for them that I have used at every customer since. This article is aimed at sharing with you this method, and explaining why it has been so effective.
Challenge
When we integrate a DNS zone into Active Directory the DNS database is stored within the AD database. This is a phenomenal function of Microsoft DNS, as it provides a level of fault tolerance and availability to DNS that to this day has no equal. Not to mention, it allows us to take advantage of other services that AD has to offer (i.e.-DNS record security, access control,…).
The downside of this is that if the DNS database is corrupted, the data has to follow the same restoration method that the Active Directory database itself requires. This may entail rebooting the domain controller and performing an authoritative restore. This can be time consuming, and painful for any administrator or organization. Additionally, there is no easy method to backup just the DNS database from AD.
Simple Backups
In order to overcome the standard limitations with the backup and recovery of DNS, I suggest a few simple steps. The DNS service itself really has very little overhead. Any computer in your network can handle running the service, and that is just what I am planning for. In order to provide simple backup of the DNS database, just setup DNS on a member server. You should not point any servers or clients to this DNS server, and could even go as far to block DNS requests from hitting the box.
The member server will not be a domain controller, so it cannot integrate DNS into AD. This will leave us with the options of primary and secondary standalone DNS zones that can be configured on this server. The great part about stand-alone DNS zones in Microsoft DNS, is that they write out the database to a text file. This text file lives in the %systemroot%system32dns folder under the name of the zone(s) you have configured. If we then use this member server to create a secondary of each AD-Integrated zone in our environment, the member server will use normal DNS replication (instead of AD replication) to transfer the zone locally and save it to a text file. The text file can then be backed-up or copied on a regular basis. This file is naturally tiny, and even smaller when compressed, so I typically recommend a simple script to copy the file daily (using the date in the file name) and keep some history of files.
Restoration
So now you have a backup (and in a form that you can manipulate easily if you so choose), let’s pretend that your AD-Integrated DNS gets corrupted somehow (probably because of a replication problem or you may not have setup scavenging correctly: Link). How can we now use this DNS backup?
This is actually really simple. The first thing to do is to identify a “good” copy of the zone(s) from the backups that we have taken. Once we have this file(s), we should place it on a domain controller from which changes would replicate the fastest (or in other words from which the domain would converge the fastest).
Next you will delete the AD-integrated zone. Choose a domain controller that seems like it is in the most appropriate location for replication to be expedited (likely the same server we copied the backup DNS Database file to), and remove any of the DNS zones that are corrupted. Wait for replication to occur, or force replication to speed up the process.
Once replication has occurred and you are confident that the zone has been removed from the environment, simply add the zone(s) back to the selected domain controller, except this time configure them as primary standalone zones. After you do this, stop the DNS service. Copy the backup files from the member server to the %systemroot%system32dns folder overwriting any files there. Once the files are copied restart DNS on the domain controller, then change the zone type(s) from “Primary-Standalone” to “Primary-AD integrated”. Now sit back, wait for replication to occur and for DNS functionality to be restored (or hurry things along by forcing replication again).
Summary
My favorite part of this solution is that it is native to DNS. Similar things can be accomplished through scripts or 3rd-party programs, by as a high-school gym teacher once said “Keep It Simple Stupid” (or K.I.S.S.). Because this is all native, it is all supported by Microsoft. It falls within best practices and requires little administrative, network, or server resources to accomplish. Let’s also add that it is relatively fast to both setup and to restore DNS by using this method.