How to Consolidate Many Reverse DNS Zones into Fewer Larger Reverse DNS Zones
I just finished a large project consolidating hundreds of 16 bit and 24 bit Reverse DNS zones into a larger global 8 bit Reverse DNS Zone and configuring that zone to be an Active Directory Integrated (ADI) DNS Zone in the ForestDNSZones partition (replicated to all DNS Servers that are also domain controllers in the forest). This article walks through the process of consolidation and all DNS Server names, IP Addresses, and domains are fictitious to ensure customer confidentiality.
The scenario:
The customer had tens of thousands of DNS nodes and about 250 Reverse DNS Zones. None of the Reverse DNS Zones were replicated at all and the DNS infrastructure was configured as Standard Primary Zones and then Secondary Zones on other DNS Servers. This resulted in an administrative nightmare and single points of failure on all Reverse DNS Zones. Furthermore, since the Reverse DNS Zones were not ADI zones, the customer was unable to configure the zones to allow only secure dynamic updates and, therefore all clients could hijack and register DNS node PTR records even if they were not joined to the domain. My laptop could even register PTR records in DNS. It was necessary to mitigate this risk and, therefore, the project called for a mass consolidation and migration to ADI zones.
Roughly 40 DNS Servers exist in the enterprise which consists of 6 separate domains within the same forest. Half of the DNS Servers were not domain controllers and, therefore, cannot host ADI zones. Each domain had specific subnets assigned to it and there were some overlapping subnets to take into consideration. For the sake of simplicity in this article, let's give the domain controllers, DNS Servers, and Reverse DNS Zones fictitious names:
(Note: Many domain controllers, DNS Servers, and Reverse DNS Zones have been excluded from this article to save time. The configuration of other domains, other Reverse DNS Zones, domain controller names, and DNS Server names were the same and the process of the consolidation is the same process for all domains and Reverse DNS Zones.)
Domain Controllers with DNS:
Oregon Domain Controllers:
ORDCDNS1, ORDCDNS2, ORDCDNS3
Washington Domain Controllers:
WADCDNS1, WADCDNS2, WADCDNS3
California Domain Controllers:
CADCDNS1, CADCDNS2, CDDCDNS3
Nevada Domain Controllers:
NVDCDNS1, NVDCDNS2, NVDCDNS3
Idaho Domain Controllers:
IDDCDNS1, IDDCDNS2, IDDCDNS3
DNS Servers that are not domain controllers:
Oregon DNS Servers:
ORDNS1, ORDNS2, ORDNS3
Washington DNS Servers:
WADNS1, WADNS2, WADNS3
California DNS Servers:
CADNS1, CADNS2, CADNS3
Nevada DNS Servers:
NVDNS1, NVDNS2, NVDNS3
Idaho DNS Servers:
IDDNS1, IDDNS2, IDDNS3
Some examples of the fictitious Reverse DNS Zones:
Oregon Reverse DNS Zones:
10.in-addr.arpa (10.x.x.x Subnet)
1.10.in-addr.arpa (10.1.x.x Subnet)
2.10.in-addr.arpa (10.2.x.x Subnet)
15.1.10.in-addr.arpa (10.1.15.x Subnet)
16.1.10.in-addr.arpa (10.1.16.x Subnet)
17.1.10.in-addr.arpa (10.1.17.x Subnet)
About 100 other Reverse DNS Zones have been excluded to save time.
ORDNS1 was configured with all Reverse DNS Zones as the Standard Primary and ORDNS2, ORDNS3 as well as some of the domain controllers were all loading these Reverse DNS Zones as secondary zones and transferring the zone data from ORDNS1. Furthermore, DNS Servers and some domain controllers in all other domains were also loading these zones as Secondary Zones and transferring from ORDNS1.
Washington Reverse DNS Zones:
5.1.10.in-addr.arpa (10.1.5.x Subnet)
6.1.10.in-addr.arpa (10.1.6.x Subnet)
5.2.10.in-addr.arpa (10.2.5.x Subnet)
6.2.10.in-addr.arpa (10.2.6.x Subnet)
18.1.10.in-addr.arpa (10.1.18.x Subnet)
19.1.10.in-addr.arpa (10.1.19.x Subnet)
About 100 other Reverse DNS Zones have been excluded to save time.
WADNS1 was configured with all Reverse DNS Zones as the Standard Primary and WADNS2, WADNS3 as well as some of the domain controllers were all loading these Reverse DNS Zones as secondary zones and transferring the zone data from WADNS1. Furthermore, DNS Servers and some domain controllers in all other domains were also loading these zones as Secondary Zones and transferring from WADNS1.
California, Idaho, Nevada, and Utah were all configured with Reverse DNS zones mimicing the overlap in subnets. We'll stop here and get to the process.
Step 1: Configuring a "Big 10" Reverse DNS zone as an ADI (Active Directory Integrated) DNS Zone and Replicating to all DNS Servers in the Forest
The current 10.in-addr.arpa zone on ORDNS1 was converted to an Active Directory Integrated DNS Zone by selecting the option to Store the zone in Active Directory (available only if DNS Server is a domain controller) . Then, the replication scope was configured to replicate To all DNS Servers in the Active Directory forest contoso.com. This allowed the 10.in-addr.arpa (10.x.x.x Subnet) to replicate to all DNS Servers that were domain controllers in the forest. Any DNS Server in the forest that was not a domain controller was not able to load this ADI zone and, therefore, secondary zones were created on all DNS Servers that are not domain controllers. Clients in all sites within all domains are configured to point their DNS settings in TCP/IP Properties to use the DNS Server in their own site and as we consolidate to one big 10.in-addr.arpa zone we would need this 10.in-addr.arpa zone populated on all DNS Servers.
So now all DNS Servers have the big 10.in-addr.arpa zone loaded as either an Active Directory Integrated DNS Zone or a Secondary Zone transferring from a couple of DNS Servers that are domain controllers.
(Note: For the transfer to be successful, we had to allow zone transfers by editing the Zone Transfer setting on the 10.in-addr.arpa zone.)
Step 2: Consolidation
As you saw in the Reverse DNS Zones configuration of these DNS Servers, these DNS Servers load multiple zones that are not only 16 bit but also 24 bit on the same server.
An example of what I am talking about would be:
10.in-addr.arpa
1.10.in-addr.arpa
2.10.in-addr.arpa
3.10.in-addr.arpa
15.3.10.in-addr.arpa
etc....
Because these zones exist on the same server, DNS creates an automatic delegation in the parent zone that delegates the child zone back to itself. Looking in the 10.in-addr.arpa Reverse DNS Zone, you see many child domains such as 1, 2, 3, 4, 5, etc. Because the DNS Server loads these other child zones, the 1, 2, and 3 child domain zones have an icon different from the other non-delegated zones. The delegation is a greyed folder and the non-delegated have the original yellow colored folder as the icon.
The process to consolidate more detailed Reverse Zones into a larger 10.in-addr.arpa zone requires zone exports, manipulating the data and then importing into the big 10.in-addr.arpa zone. The import will be unsuccessful if a delegation still exists and, therefore the delegated zone must be deleted just before the import.
The Tool: DNSExporter (obtainable from Microsoft Support under the toolbox search phrase of "DNS Record Export")
DNSExporter allows zone enumeration in tab delimited format and provides information about the record owner, whether or not the record is dynamic or static and whether or not the record is stale. It is quite useful in environments where aging is turned on for specific zones but scavenging has not been set on any servers. This tool will export the zones and provide a list of all records that would be scavenged if it were enabled on the server. However, I used it for zone export and import only.
The Process:
Open DNS Exporter (shown in Figure 1)
Figure 1
In the DNS Server Name field, type the name of the DNS Server that contains the Primary zone to be exported. The File Name field defaults to c:\DNS_ZONE_EXPORT.txt but I found it useful for backup purposes to change the export file to the name of the reverse zone.
The Export Restrictions field is blank by default but must be populated with the name of the zone you want to export. In my example of exporting the 226.10.in-addr.arpa zone, the Export Restrictions field should read where ContainerName="226.10.in-addr.arpa" .
The Record Type drop down should be changed to MicrosoftDNS_PTRType.
Providing the user account being used to export the zone information is an administrator of the DNS Server, no credentials are necessary.
Click on Export and you will see the Records Processed field start to export records.
The exported data text file will contain tab delimited results. Open the exported text file using Microsoft Excel. The information will looks something like:
Record Type ContainerName DnsServerName DomainName OwnerName
MicrosoftDNS_PTRType 226.10.in-addr.arpa ordns1.or.contoso.com 226.10.in-addr.arpa 240.12.226.10.in-addr.arpa
MicrosoftDNS_PTRType 226.10.in-addr.arpa ordns1.or.contoso.com 226.10.in-addr.arpa 4.12.226.10.in-addr.arpa
MicrosoftDNS_PTRType 226.10.in-addr.arpa ordns1.or.contoso.com 226.10.in-addr.arpa 44.12.226.10.in-addr.arpa
MicrosoftDNS_PTRType 226.10.in-addr.arpa ordns1.or.contoso.com 226.10.in-addr.arpa 20.20.226.10.in-addr.arpa
MicrosoftDNS_PTRType 226.10.in-addr.arpa ordns1.or.contoso.com 226.10.in-addr.arpa 254.20.226.10.in-addr.arpa
MicrosoftDNS_PTRType 226.10.in-addr.arpa ordns1.or.contoso.com 226.10.in-addr.arpa 254.20.226.10.in-addr.arpa
MicrosoftDNS_PTRType 226.10.in-addr.arpa ordns1.or.contoso.com 226.10.in-addr.arpa 4.20.226.10.in-addr.arpa
There are more columns to the right but they have been snipped to show only the relevant columns that need to be manipulated. Do not remove the extra columns as they are still needed for the import.
In order to import these records into the "Big 10" Reverse DNS Zone, the ContainerName and the DomainName columns have to be manipulated to import into the correct zone. The columns for ContainerName and DomainName should be column B and column D respectively. Change cell B2 and D2 to read 10.in-addr.arpa and then drag replace within Excel all the way down the entire column list of records to overwrite with the new 10.in-addr.arpa values.
Save this tab delimited text file as <something>-import.txt. You will be prompted with an informational warning that the file may contain features that are not compatible with Text (Tab delimited). Click Yes to allow this.
Now using DNS Exporter, change the DNS Server Name field to the name of a domain controller containing the 10.in-addr.arpa Reverse DNS Zone. Also change the File Name to the text file you just saved in the last step.
Before you click on Import, check the 10.in-addr.arpa Reverse DNS Zone to ensure that there is not currently a delegation for the 226 child zone. If there is, it must be deleted prior to importing. Then click Import. The Records Processed data will begin to process the importation of the records.
Now, the Primary Zone 226.10.in-addr.arpa can be deleted on ORDNS1 as well as the Secondary Zones that exist on other DNS Servers. Follow the same steps for all 16 bit and 24 bit Reverse DNS Zones in order to import into the "Big 10" Reverse Zone.
While onsite with my customer, I also built a batch file that would do dnscmd queriy commands against the import server to ensure that these records were in fact imported. In order to build the script, I had to build a records.txt text file that had the PTR records to look for. To get this text file I used my DNS Export output file. There is a column in the output called OwnerName (included above) that contains the PTR information. I copied that entire column to Notepad and did a Replace all. I replaced .10.in-addr.arpa with nothing and saved that file as records.txt. Then the batch file was built and looked like this:
@echo off
for /f "tokens=1" %%i IN (records.txt) DO dnscmd.exe ordc1 /enumrecords 10.in-addr.arpa %%i >> recordresults.txt
After that was run, I searched through recordresults.txt and searched for the word failed. If a record was not found in the query, the output would be similar to:
DNS Server failed to enumerate records for node 4.225.1.10.in-addr.arpa.
I also built a batch file to use dnscmd to delete the secondary zones on all DNS Servers.
The script used to remove all secondary zones needs a file called servers.txt populated with all DNS Servers. The script looked like this and had to be edited for every zone that was to be deleted:
@echo off
FOR /F "tokens=1" %%i IN (SERVERS.TXT) DO dnscmd %%i /ZoneDelete 226.10.in-addr.arpa /f
The same process was repeated for all Reverse DNS Zones. Hope this helps!
UPDATED!
Ashley McGlone has written a PowerShell script to perform similar functions. His Blog is located here....