03-29-2017 07:59 AM
So I know it will work either way but what is the correct / proper way to organize your in-addr.arpa records
OPTION A - no containers (everything is at root)
OPTION B - using containers
10.in-addr.arpa works like a container then you have subzones
Let me know if you ran into any issues going either way. We have a mixbag of both and I would like to clean up our environment of reverse records and would like to know the correct way to go.
03-30-2017 05:47 AM - edited 03-30-2017 05:48 AM
I think you are mixing up reverse zones and network containers, the two are not related.
For network containers, I would create a 10.0.0.0/8 container and put all your 10.* networks underneath. You can further containerise if you want. The advantage of having the top level container is that you can use the network map view to get a global view of your address space utilisation.
For the reverse zones, they do not need to "map" onto containers at all. I try and keep the number of reverse zones to a minimum. I recommend creating a 10.in-addr.arpa top level reverse zone so that you are authoritative for the whole of the RFC1918 10.* address space, if you don't do this then you can end up with queries being forwarded out to the Internet or other wierd things going on (timeouts/server failure type responses etc.).
If you need to split it up further, e.g. maybe you need to delegate some part of the reverse space to other servers within your organisation, then depending on how you have carved up your address space you may want to delegate /16's, but I try to avoid going all the way down to /24's for the reverse zones, it's just not necessary (apart from cases where you do need to delegate small parts of the address space).
The simpler you can keep the reverse zone structure the easier it'll be to manage. There's really no point carving them all up if they sit on the same server(s) unless you have specific requirements (e.g. maybe you need to do some granular admin permissions).
PCN (UK) Ltd
All opinions expressed are my own and not representative of PCN Inc./PCN (UK) Ltd. E&OE