How to sort out a reverse DNS mess

[LukeC_2021]

Hi,

Our organization has a number of 10.X.0.0/16 locations with the same AD/DNS name ourcompany.com. No worries.

We are connected to a separate company with the AD/DNS name othercompany.com who were using some 172.16.XXX.0/22 addresses. Still good.

We used conditional forwarders on each companys DNS records to forward each others forward and reverse lookup queries to the other. Great.

But now, othercomapny.com is moving over to 10.X.0.0/16 network ranges.

We have hit a snag on the ourcompany.com DNS server in that the reverse lookup zone is 10.in-addr.arpa instead of each individual X.10.in-addr.arpa zone. This means the ourcompany.com DNS server cannot create a conditional forwarder for 44.10.in-addr.arpa as this overlaps with our 10.in-addr.arpa zone. As a result we cannot reverse lookup othercompany.com IP addresses.

Deleting our reverse lookup zone 10.in-addr.arpa sounds pretty horrifying, so I am wondering is there a best approach to doing this? Is it possible at all?

I appreciate any advice anyone can give.

[#2]

@LukeC_2021 Sad that no one has replied to this yet. I was browsing the web as I’ve run into an identical issue with a client and wanted to see if anyone else had a better idea than my own. Since I haven’t found anything I’ll offer my best suggestion. You could export the zone, then delete the 10.in-addr.arpa zone, and finally reimport a reconfigured zone scoped down to /8 /16 /32 class based. It might be easier to first convert the zone to be non-ad integrated as the format would be easier to work with when exported compared to registry entry format that an ad integrated zone is in. If dynamic updates are not a concern you can further scope out a reverse lookup zone to a classless zone like /26 /23 by right clicking the class based zone and selecting new domain which will let you configure a classless zone. Keep in mind though that you still can’t have an overlap of reverse lookup zones between forests as each is considered its own root domain. You can use the method I described within a single forest to segment out the larger scope and allocate the smaller subnets to child domains at the cost of losing dynamic updates.