Reverse zones best practices

[Mark Andrews]

I would set up 10.in-addr.arpa which is slaved on all internal
nameservers and delegate the /24's as required.  10.in-addr.arpa
won't change much and will be cheaper in the long run than using a
stub zone.

In message <4FEB2A8A.4050002 at imperial.ac.uk>, Phil Mayers writes:
> On 27/06/12 15:30, nex6 wrote:
> 
> > so, you *should* have a larger 10.x.x.x zone? *and* smaller
> > 10.x.x.0/24 zones? so i am assuming the workflow would be in this
> > case, records go in the smaller zones, and the larger zone is the
> > catchall to prevent leakage?
> 
> It is good practice, and polite, to prevent leakage of reverse DNS 
> queries for the private IP ranges.
> 
> You can accomplish this two ways:
> 
>   1. Have a "zone" statement for every /24 inside 10/8 e.g.
> 
> 0.0.10.in-addr-arpa
> 1.0.10.in-addr.arpa
> ...
> 255.255.in-addr.arpa
> 
> You could use empty/dummy zones (maybe even the same zone file) for 
> zones which don't have actual contents defined.
> 
> 
>   2. Have a "10.in-addr.arpa" zone *and* the smaller zones. If you do 
> this, you might want to take the time to insert the proper delegations 
> inside the 10.in-addr.arpa zone to the smaller zones, even if they're on 
> the same servers. It might work without that, but there might be 
> circumstances where it won't - I'm not sure.

It won't work is 10.in-addr.arpa is signed and you have validating clients
that know the trust anchor for it.

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org