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.4050...@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@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: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
