How can your organization benefit from savings just by replacing your legacy backup solutions with Acronis' #CyberProtection? Join Forrester's Joe Branca and Ryan Davis from Acronis live as they explain how you can too.
Can I consolidate my Reverse Lookup Zones by specifying a more general zone? Are there tools to help me with the records migration?
Folks -
I'd like to reduce the number of Reverse Lookup Zones I have in my forest. I'm wondering if its possible to do this by specifying a zone with a smaller bit mask and removing the zones with larger masks?
In other words... let us say I own the entire 199.200.x.x Class B range. If I have a reverse lookup zone for 199.200.100, 199.200.101, 199.200.102, etc. Is it possible to consolidate these into one zone named 199.200.x.x rather than specifying each Class C segment? This would allow me to significantly reduce my number of zones with no impact (as far as I see it - am I wrong?)
Second question - Are there any tools to help me migrate the records, static or otherwise, from one zone to another?
Let me know if I need to clarify what I'm after here.
I'd like to reduce the number of Reverse Lookup Zones I have in my forest. I'm wondering if its possible to do this by specifying a zone with a smaller bit mask and removing the zones with larger masks?
In other words... let us say I own the entire 199.200.x.x Class B range. If I have a reverse lookup zone for 199.200.100, 199.200.101, 199.200.102, etc. Is it possible to consolidate these into one zone named 199.200.x.x rather than specifying each Class C segment? This would allow me to significantly reduce my number of zones with no impact (as far as I see it - am I wrong?)
Second question - Are there any tools to help me migrate the records, static or otherwise, from one zone to another?
Let me know if I need to clarify what I'm after here.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Yes, you can do that.
Tools: At least you only have one record type to deal with :)
My PowerShell DNS module can do it:
http://dnsshell.codeplex.com/
Something along the lines of this, although I reserve the right to have forgotten and may need to check tomorrow:
Chris
Tools: At least you only have one record type to deal with :)
My PowerShell DNS module can do it:
http://dnsshell.codeplex.com/
Something along the lines of this, although I reserve the right to have forgotten and may need to check tomorrow:
Get-DnsZone -Reverse | Where-Object { $_.ZoneName -Match '\d{3}\.200\.199' } | ForEach-Object {
Get-DnsRecord -RecordType PTR -Zone $_.ZoneName | New-DnsRecord -Zone "200.199.in-addr.arpa"
}
Chris
Thanks Chris!
Not to pile on to the question but... how hard would it be for you to whip up a PowerShell script that would report all static records that are not of SOA or NS type? The script could run against all reverse lookup zones in the entire domain.
I'm essentially looking for static stragglers or dynamics that I might need to watch out for. Is this a royal pain?
Not to pile on to the question but... how hard would it be for you to whip up a PowerShell script that would report all static records that are not of SOA or NS type? The script could run against all reverse lookup zones in the entire domain.
I'm essentially looking for static stragglers or dynamics that I might need to watch out for. Is this a royal pain?
Not hard at all, but I'll have to test it properly in the morning, no MS DNS servers at home, only BIND.
Chris
Chris
Tell you what, hold off on that if you would. I don't want you to do something I might not need.
I'm just struggling with how to properly do this. I don't want to run off haphazardly deleting zones.
If I create a zone that "overlaps" others with a small mask, will clients register there instead? In other words, let's say I create a zone for 199.200.x.x and I have a bunch of other zones already defined with a larger mask, say 199.200.100 and 199.200.101. Will the registrations begin to occur against 199.200? Or will the PTR records continue to update against the old zones, at least until the timestap expires?
My worry is wiping out records and temporarily breaking an application that does require a reverse lookup record until DNS registration reoccurs. So I'd rather create a new zone, have clients begin to register there, move over the static records manually as there aren't that many, and then delete the old zones in time, perhaps weeks. Is this a valid strategy?
Thanks for all the help Chris. Most appreciated.
I'm just struggling with how to properly do this. I don't want to run off haphazardly deleting zones.
If I create a zone that "overlaps" others with a small mask, will clients register there instead? In other words, let's say I create a zone for 199.200.x.x and I have a bunch of other zones already defined with a larger mask, say 199.200.100 and 199.200.101. Will the registrations begin to occur against 199.200? Or will the PTR records continue to update against the old zones, at least until the timestap expires?
My worry is wiping out records and temporarily breaking an application that does require a reverse lookup record until DNS registration reoccurs. So I'd rather create a new zone, have clients begin to register there, move over the static records manually as there aren't that many, and then delete the old zones in time, perhaps weeks. Is this a valid strategy?
Thanks for all the help Chris. Most appreciated.
They always register in the most specific zone, so if you overlap they will still continue to register in the sub-domain (the "class c"). This will occur as long as the more specific zone exists, it's not time-stamp bound.
I'd be tempted to drop the dynamic records on import anyway, there's no way for us (at the moment at least) to import them with timestamps intact. All dynamic records would become static, it makes cleaning up afterwards hard work.
It would be rare for an application to be dependent on reverse lookup, but I can appreciate your concern.
Chris
I'd be tempted to drop the dynamic records on import anyway, there's no way for us (at the moment at least) to import them with timestamps intact. All dynamic records would become static, it makes cleaning up afterwards hard work.
It would be rare for an application to be dependent on reverse lookup, but I can appreciate your concern.
Chris
Premium Content
You need an Expert Office subscription to comment.Start Free Trial