Forum Discussion
Creating parent reverse lookup zone when child zones already exist — what happens?
We have an AD-integrated DNS environment that has accumulated a large number of reverse lookup zones over time, created without any parent zone — essentially DNS sprawl from years of admins creating individual subnet zones rather than working from a parent.
We currently have approximately 80+ reverse lookup zones including:
- Dozens of x.10.in-addr.arpa zones covering various 10.x.x.x subnets
- Multiple x.172.in-addr.arpa zones
- A handful of others including 100.192.10.in-addr.arpa, 168.192.in-addr.arpa, 204.167.in-addr.arpa, 215.204.167.in-addr.arpa, 135.7.in-addr.arpa
None of these were ever delegated from a parent zone — they were just created independently. The 10.in-addr.arpa zone does not exist.
Domain controllers are a mix of Windows Server 2019 Standard (majority) and Windows Server 2025 Standard.
Our goal is to create 10.in-addr.arpa as the consolidation point going forward — new registrations go there, and we migrate existing child zones into it one at a time, deleting old ones as we go at a pace we're comfortable with.
Before touching anything, we need to understand what creating 10.in-addr.arpa will actually do to the existing child zones.
Specifically:
- Will existing records in the child zones be deleted? We've seen the TechNet article documenting records vanishing when creating a child zone under an existing parent — does the same destructive behaviour occur in the reverse direction?
- Will auto-delegations be created in the new parent zone pointing to the existing child zones, and if so how quickly?
- Will the child zones continue to function normally for queries while the parent exists alongside them?
- Will dynamic registration start hitting the parent zone for subnets not covered by an existing child zone, or will something unexpected happen?
We can't test this in a lab as we don't have a replica environment available, and can't risk touching production without understanding the behaviour first. Pointers to any documentation covering this specific scenario would also be appreciated — we've been unable to find anything that addresses creating the parent after the children already exist independently.
1 Reply
Hi, I would be careful and test this before changing production AD-integrated DNS. Creating a parent reverse zone should not automatically merge or delete existing child reverse zones, but delegation/lookup behavior can get confusing if the zones overlap.
My safe approach would be:
1. Export or document the existing reverse zones first.
2. Test the same layout in a lab if possible.
3. Create the parent zone only after confirming how the child zones are delegated.
4. Avoid duplicate PTR records across parent and child zones.
5. Clean up gradually, one subnet/range at a time.
The main risk is not the zone creation itself, but duplicate or ambiguous reverse lookup ownership afterward.
