Have you ever wanted to roll up all of your reverse zones into a "big 10" super zone? Do you need to copy DNS zones between environments and preserve the record aging? Today's post is for you.
Author’s note: While flying home on a Friday night this blog post was mostly composed on my Windows Phone in OneNote, synced to OneDrive, continued from my laptop, pasted into Windows Live Writer, and then posted to TechNet. I love OneNote for being productive on-the-go!
Have you ever reviewed the first PowerShell scripts you wrote? Yeah. It's painful. The only difference is that mine are public here on TechNet. I've learned so much since I started blogging about PowerShell four years ago. People are still finding and using some of my first scripts.
For the last year I have been wanting to update my DNS zone consolidation script. I posted this one in September of 2010. Recently I had a customer who needed this solution, and it gave me the perfect chance to improve it.
NOTE: Today's article references many DNS terms and concepts. If these are unfamiliar to you I would recommend reading up on DNS using the links on this page. http://aka.ms/AD101
Traditionally if you want to copy a DNS zone to another environment you just create a secondary copy of the zone at the destination, pull the records from the primary, then promote the secondary copy to a primary. The only issue here is that secondary zones lose the time stamping, and that may be a deal breaker for some folks.
Another way is to do a zone export with DNSCMD first. Then you copy that to the destination server, create a new zone, and point it to the export file. Unfortunately when you create a new zone on Windows DNS it defaults to no aging. When you go back to the new zone to enable aging after it is created the timestamps were lost during the import to the new zone lacking aging.
These comments are based on my own experience. If you know other ways to achieve the goal of copying a DNS zone with timestamps in tact please tell us in the comments below.
My original script used WMI exclusively, limitations and all. I've used DNSCMD with other scripting solutions, but it is now deprecated in Windows Server 2012. It still works, but it is not guaranteed to be there in the future. Check out this output at the bottom of the help for DNSCMD:
PS C:\> dnscmd /?
Usage: DnsCmd <servername> <command> [<command parameters>]
In future versions of Windows, Microsoft might remove dnscmd.exe.
If you currently use dnscmd.exe to configure and manage the DNS server,
Microsoft recommends that you transition to Windows PowerShell.
To view a list of commands for DNS server management, type
"Get-Command -Module DnsServer" at the Windows PowerShell prompt. Additional
information about Windows PowerShell commands for DNS is available at
NOTE: For a handy guide to moving your DNSCMD commands to PowerShell see this link.
With Windows Server 2012 we released a ton of great cmdlets to script DNS. As luck would have it this particular customer was still using Windows Server 2003 R2 for all of their domain controllers (in the year 2014). Fortunately this was not a problem. They set up a Windows Server 2012 tools server in a dev forest, and we ran all the new cmdlets from there. So yes, the new DNS cmdlets work well even when targeting legacy operating systems.
Over the years many AD shops have treated reverse DNS as a step-child. We touch it only when someone complains that the crusty old app using reverse DNS is broken again. And then often the folks implementing the fix don't have a good grasp of the way DNS works. This leads to a hodgepodge of reverse zones that are very outdated and very cumbersome to administer. Nine times out of ten the nameserver records for all those zones never get updated when domain controllers come and go.
This particular customer had nearly 350 reverse zones. We consolidated them down to 5. Keep reading to find out how.
TIP: Active Directory itself has ZERO dependencies on reverse DNS.
Now you may be thinking... "Reverse zone consolidation is easy. Just delete all of them. Create one big 10.in-addr.arpa and let the clients reregister dynamically." In most cases that would work, except for two issues:
This being the case we needed to preserve all of the existing reverse DNS records.
This same scenario could apply to forward zones, but it is less common. You can use the same code to roll up separate subzones into a single parent zone.
At the same time this customer had not run scavenging for two years. The reverse zones were full of old data that did not need populated in the new, consolidated zones. We turned scavenging back on, but we didn't have time to wait for the first big pass of deletions.
In case you think I'm picking on this customer, then don't take this the wrong way. I've seen the same issues at many customers. I am calling out these examples, because they are real world. I'm guessing you are still reading, because you “know someone” with similar issues.
My first script had a number of limitations:
Time for a PowerShell make-over.
Recently a different customer came to me with an unusual request. They wanted to script building out reverse DNS zones based on data in the forward zones. I wrote a script to read all of the A and CNAME record data from the forward zones and then created new reverse zones where I populated new records. This scenario was a long story, but it was not a good solution for this week's customer.
The better approach was to copy all of the /16 and /24 reverse zones up into the top level /8 zones. Some people call these "super zones" or a "big 10". After the records were copied we would delete the old zones.
To make this work we need to execute the following steps:
I have done this with multiple customers. I always recommend working from a DC DNS server where no clients are pointing for name resolution. We create the new top-level zones as standard primary (text file based) first. Then when the zone consolidation looks good we turn them up to AD integrated and let them replicate out.
By default new records are static. In my code I check the source record to see if it has a timestamp. If not, then we add a static record. If it has a timestamp, then we use the -AgeRecord switch with the cmdlet. Here is the rub. You cannot copy the exact timestamp from the old record to the new one. Therefore any dynamic records will get a fresh timestamp. This may cause a hiccup in your scavenging, but it should not be a significant issue.
Since I knew many of the records in the source zone were already stale I added a -StaleDays parameter to my DNS zone copy function. Any dynamic record whose timestamp is older than this value will not be copied.
In this solution we use the following cmdlets from the PowerShell module DnsServer:
We use these cmdlets to build new functions to help with finding and copying the zones. Note that these cmdlets are only available on Windows Server 2012 and above, or Windows 8.0 Remote Server Administration Tools (RSAT) and above. All you need is a Windows Server 2012 tools server somewhere in your environment. Get a list of DNS cmdlets this way: Get-Command -Module DNSServer, DNSClient -or- use Show-Command and filter on the DNS modules.
Copy-DNSServerZone will do exactly what it sounds like. It copies a single source zone from a source server to a destination zone on a destination server. The source and destination servers can be the same or different. Currently this function only handles A, CNAME, PTR, MX, and SRV records. Feel free to add other record types as needed. Note that we automatically exclude copying NS or SOA records, because those are unique to the destination server.
Copy-DNSZoneReverse is a calling function to automate enumerating all of the reverse zones in source/destination pairs for the consolidation. It will automatically find all the /16 and /24 reverse zones that need to be copied into the /8 zones and pass them to Copy-DNSServerZone. All you need to supply are the source and destination servers.
Remove-DNSZoneReverse will remove all DNS reverse zones except the top-level ones (10.in-addr.arpa, etc.). It is much faster than manually deleting a couple hundred reverse zones. Obviously be careful with this. Just to be safe my version forces you to confirm each zone deletion.
Points to plan for:
NOTE: I have included other handy DNS functions in the script download for this article.
Using these custom PowerShell DNS functions you can now automate your DNS zone roll ups using commands like this:
# Log all console output
# Dot source to import the DNS functions
# Example: Copy a single zone
Copy-DNSServerZone -SrcServer dc1.contoso.com -SrcZone "1.5.10.in-addr.arpa" `
-DestServer dc1.contoso.com -DestZone "10.in-addr.arpa" `
# Example: Roll up all reverse zones
Copy-DNSZoneReverse -SrcServer dc1.contoso.com -DestServer dc2.contoso.com
# Allow time for replication if needed
# Verify that the consolidated zones look good
# Troubleshoot any errors
# Example: Remove all but the top-level reverse zones
Remove-DNSZoneReverse -Server dc2.contoso.com
# Save the log
These are examples of how you can use the commands. Don’t run it exactly like these samples. Using the steps highlighted above and this sample code you can create your own automated process. Remember to take a backup before you start and allow time for replication afterward.
Download this DNS function library at the TechNet Script Center.
If you would like to have me or another Microsoft PFE visit your company and assist with the ideas presented in this blog post, then contact your Microsoft Premier Technical Account Manager (TAM) for booking information.
For more information about becoming a Microsoft Premier customer email PremSale@microsoft.com. Tell them GoateePFE sent you.
Really liked this. The author notes at the start especially. Well done.
amazing stuff as always