On Sun, 2011-07-24 at 01:01 +0000, Laws, Peter C. wrote: > Decloaking to ask for pointers to some help regarding RFC 1918 zone > delegation. > > We use 10/8 space extensively over multiple campuses. We need to > delegate at the 10/ essentially, the 10/16 level. Is there a better > way to do it than
Maybe this is an overly naive approach, but can't you set up one zone for 10.0.0.0/8 and delegate as necessary from that single zone file? Anything that you don't have an answer for will get NXDOMAIN, which is presumably what you want. So: zone "10.IN-ADDR.ARPA" { type master; file "internal/db.10.rev"; allow-query { network_internal; }; }; Then in the zone file internal/db.0.rev: $ORIGIN 10.in-addr.arpa. [...] 0 3600 IN NS ns00.mydomain. 1 3600 IN NS ns01.mydomain. ... etc Your forward zone for mydomain would need entries for the ns00, ns01 etc. ns00, ns01 etc are the nameservers to which 0.10.in-addr.arpa, 1.10.in-addr.arpa etc are delegated. Those servers will then have conf entries like: zone "0.10.IN-ADDR.ARPA" { type master; file "internal/db.10.0.rev"; allow-query { network_internal; }; }; and in the zone file internal/db.10.0.rev on ns00, for example, entries for the subnet: $ORIGIN 0.10.in-addr.arpa. [...] @ 3600 IN NS ns00.mydomain. ... 1.1 3600 IN PTR gw.mydomain. 2.1 3600 IN PTR somehost.mydomain. ... etc The other delegated nameservers would have zone files like db.10.1.rev, db.10.2.rev etc with the appropriate zone data for those /16 subnets of 10.0.0.0/8. In short, all the delegations are in one zone file. You do still need one delegation per delegated subnet, there's no way around that. All this is off the top of my head, so treat with great caution :-) Regards, K. > zone "1.10.IN-ADDR.ARPA" { > type master; > file "internal/db.10.rev"; > allow-query { network_internal; }; > }; > > zone "2.10.IN-ADDR.ARPA" { > type master; > file "internal/db.10.rev"; > allow-query { network_internal; }; > }; > > et cetera, ad nauseum and then putting in NS records as necessary? > > A little less than half of the zones would remain with us with the other > half-and-a-bit delegated away. > > I'm afraid of the answer since I fear I'm stuck with making 256 zones ... > > BIND 9.3 as hacked by Red Hat, though now that we found the bind97 packages > in the supported repo, we may go with that. > > -- > Peter Laws / N5UWY > National Weather Center / Network Operations Center > University of Oklahoma Information Technology > pl...@ou.edu (Remote) > _______________________________________________ > 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 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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