Windows Server: Creating a DNS Reverse Lookup Zone with Smaller Zones

Introduction

Few years back, we were dividing an existing reverse lookup zone into smaller zones. It was a production zone, containing thousands of records. At that point, we encountered some issue which is probably little known, even to the experienced system administrators. If that issue is not noticed at the right time and proper measure is not taken, it can bring severe production outage.

Today’s article is going to share that experience with you, and also a feasible solution.

Our environment is based on Windows Server 2012 R2 Domain Controllers, and we are using AD Integrated DNS Zones. All Domain Controllers in our environment are DNS servers, and vice versa.

The Activity

We have a reverse lookup zone 168.192.in-addr.arpa. This is an AD Integrated Zone.

This zone contains all reverse records for the 192.168.x.x network.

 There are records for 192.168.1.x subnet and for 192.168.2.x subnet.

 For 192.168.2.x records :

1. Some of the records are created at the time of creating host records, by selecting the option “Create Associated PTR Records”.

   192.168.2.10, 192.168.2.11 and 192.168.2.12 fall in this category. So for these records, there exist corresponding host records.

2. Some of the records are created directly as reverse records, and no host records exist for these PTR records.

   192.168.2.2, 192.168.2.3, 192.168.2.4 & 192.168.2.5 fall in this category.

Below diagram can explain the scenario better.

Now, due to some reason, we would like to break this zone into smaller zones. That means, we are going to create zones like this:

• 168.192.1.in-addr.arpa.
• 168.192.2.in-addr.arpa….and so on.

 

Once the smaller zones would be created, we would like to move all existing records from the bigger zone (192.168.x.x) to the matching smaller zone.

Create a New Zone

So, now let’s create a new reverse lookup zone: 2.168.192.in-addr.arpa.

So the new reverse lookup zone is created.

The Observation

This is the most important part of this article.

Once the new zone is created and we go to the original zone 168.192.in-addr.arpa., we have observed that all records matching with 192.168.2.x subnet is gone. We need to refresh the zone to confirm it.

We have also observed that a new delegated zone is created for 2.168.192, but that delegated zone also does not contain those missing records. Those records now exist nowhere, neither in the original zone, nor in the new zone, and nor in delegated zone. The records have simply vanished!

For those PTR records which had corresponding host records, the host records are intact and those are not deleted. But PTR records are gone.

So, to summarize, when we break a reverse lookup zone into smaller zones, all existing records matching those smaller zone subnet(s) would be deleted immediately without any warning. If there are thousands of such records, all thousands of records would be deleted immediately.

We have tested this in Windows Server 2012 R2 Domain Controller, which is also DNS Server. The testing has been performed in multiple environments, and we got the same result every time.

Dynamic Records

So far, we have only observed this behavior for static records, but what about dynamic PTR records? Are they also getting deleted?

Let’ see.

We have 3 records for 192.168.1.X subnet:

1. 192.168.1.2: Static
2. 192.168.1.5: Static
3. 192.168.1.88 (Dynamic, registered by a system, has corresponding host record)

 

Now let’s create a new zone 1.168.192.in-addr.arpa, and observe the behavior:

As we can see, dynamic record is also gone, along with static records.

Restarting DNS Server Service, and restarting the entire DNS server did not solve the issue. The records are gone !

We have also tested and found that it is not possible to restore the records from AD Recycle Bin, even if the zone is AD Integrated.

Why Records are Getting Deleted

We did not find any specific Microsoft article explaining this behavior, so we can conclude that this behavior is by design.

However, it is unclear that instead of moving those records to the newly created zone why the algorithm is deleting those records without any warning or information. We are not sure whether this is a bug or intended design.

As per this article, the records are marked as “dNSTombstoned”. Some event IDs are generated in DNS Server event logs, which are 4010 and 4013.

Is it a Vulnerability?

I logged a case with Microsoft Security Team informing this behavior. Microsoft reproduced this in their lab and confirmed that my finding is correct. While Microsoft Security Team did not classify it as a security vulnerability, they informed that in the future release of Windows they will add a warning message indicating record deletion while creating an overlapping reverse DNS Zone.

However, with this behavior present, a DNS Admin can delete thousands of records without having access in a protected zone.

Let's assume that we have a highly critical zone, with thousands of records. We would like to customize the DNS Zone permission so that only a few selected admins can delete DNS records from that zone. 

With this behavior, nobody needs to delete permission on that zone. All they need to do is to create a smaller reverse zone, and all records from the corresponding subnet would be automatically deleted from the original zone. Someone can do this accidentally or intentionally. We have tested this scenario in our test lab and records are getting deleted where most of the accounts (Authenticated Users, Everyone, Domain Admins, DNS Admins, Enterprise Admins) have "Deny" access to delete any record.

So due to this behavior, a large amount of records from a reverse lookup zone can be deleted without even having access to that zone.

The Solution

Ideally, the deleted records should go to AD Recycle Bin, because in an AD Integrated DNS Zone each record is an AD object. However, we did not find these records in AD Recycle Bin. Off course, AD Recycle Bin was enabled before deleting the records.

The only possible solution which we have found (and applied) is to recreate the records quickly in the newly created zone. For a large number of records, we have to implement some automation and that is what we did. We used a PowerShell script.

While this solution is good for Static records, for Dynamic records we recommend to re-register those records, rather than creating those manually or through scripts. Because when you create records manually (or through some script), the record type would be Static.

I have created a PowerShell script in Tech Net Gallery, called PowerDNS. This is a multipurpose script which can create, delete, query bulk DNS records.

Implementing The Solution

When you need to create such smaller reverse zone, where a parent reverse zone exists and which contains multiple records matching the (to be created) smaller zone(s) that we are going to create, you have to follow below steps:

1. Export all records from the parent zone to a text file.
2. Now, put the entire content in an Excel, and apply “Text to Column” to segregate IP addresses and Record values.
3. Filter with IP address range. For example, you are going to create a zone 168.192.3.in-addr.arpa., so you assess that all existing records for the subnet 192.168.3. would be deleted and to be re-created immediately. So from this Excel, filter only that IPs staring with 192.168.1.3.
4. Now, once this is done, create an input file like below. File format must be CSV.

Important:

• Please maintain the exact format of the header (IP,FQDN) as the script will take the input from this file. 
• Also, while specifying the records value, mention only the host octets.
• Please do not mention the network octets as the network octets would be specified while running the script.
• Put comma (,) between values.
• Do not put a semicolon or any other separator.
• Mention record FQDN.

Script Execution

Now that the input file is ready, let’s run the script. You can run it from the DNS server, or from another system where AD and DNS PowerShell modules are installed. Please make sure you have appropriate permission to create DNS records on the specified zone.

When you run the PowerDNS utility, you will see multiple options. To create PTR Records, press 3.

Since we have to create bulk PTR records, select 2.

Now enter DNS Server Name, Reverse lookup zone name and input file location.

For each record, the script will ask you to confirm.

(If you do not want confirmation box, please edit the function Create-BulkPTREntry and remove –confirm switch)

Once all records are created, you will get a message “Press Enter to Continue”. Pressing Enter would return you to the main menu.

Now, you can verify that all the reverse records are created in the correct zone.

Summary

In this article, we have explored a typical behavior of Windows DNS Server which is perhaps little known to many admins.

• When we break a reverse lookup zone into smaller zones, all existing records matching those smaller zone subnet(s) would be deleted immediately without any warning. If there are thousands of such records, all thousands of records would be deleted immediately.
• This behavior is true for Static as well as Dynamic records.
• Corresponding Host records are intact, and not getting deleted.
• The deleted records cannot be recovered from AD Recycle Bin, or any other way.
• The only possible solution we have found is to re-create the records. For dynamic records, it should be re-registered.
• We have used a PowerShell script to bulk record creation.

Last but not the least; please test this behavior and the script in a test environment, before doing anything in production.

See Also

• The Case of the Vanishing Static Reverse DNS Records