MicrosoftI know its 4 years ago - but great article.
Funny we are going through this exact process right now when I stumbled upon it.
Essentially we are breaking up the 10.in-addr.arpa zone into 1.10.in-addr.arpa, 2.10.in-addr.arpa, etc.. so we can create some conditional reverse DNS forwarders to other organization's DNS servers for reverse DNS (as well as some cloud resolvers covering some 10.X networks). Long story, but that is the way its set up for us. Those are separate AD/DNS domain's and non AD DNS resolvers that some cloud providers have.
To kick off, we restored AD/DNS to an offline environment and began testing the process. We noted (as you described) that when we create the 5.10.in-addr.arpa zone in DNS for example, all of the 10.5.X.X records that were in the original 10.in-addr.arpa disappear. Then we see the .5 subfolder under the 10.in-addr.arpa.
As you also mention, machines register themselves into DNS and correctly appear in the new 5.10.in-addr.arpa zone now which is cool - but yeah.. all those static entries are gone and never return.
Knowing this from testing means we are prepared for the loss in production. We plan to press ahead creating all of the X.10.in-addr.arpa zones until the main 10.in-addr.arpa zone is empty (except for the subfolders). When we will delete the 10.in-addr.arpa zone. At this point, we will be able to create our conditional forwarders.
For situations where a specific host reverse lookup is required, we will either push out an IPCONFIG /REGISTERDNS commend OR flip the A record 'update PTR record' switch - which we have observed creates the reverse entry in the new zone as expected.
I do not believe we will be in a panic situation like this article refers to as
No one is probably reading this anymore - but if you do happen to see it and have any feedback for something we might be overlooking or about to walk in to - I'd be greatly appreciative.
I'll reply back once this is done - just in case anyone else is in the same boat and stumbles across it future.
Thanks!
