In article <gv25eq$2n...@sf1.isc.org>, Matthew Pounsett <m...@conundrum.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 20-May-2009, at 19:03, John Cole wrote: > > > For a concrete example: > > > > 10.0.0.0/16 is presently handled by a single zone file. > > 10.1.3.0/24 is DHCP issued > > 10.1.4.0/24 is DHCP issued Note 1: 10.1.3.0/24 and 10.1.4.0/24 are not subnets of 10.0.0.0/16. Did you mean 10.1.0.0/16 or 10.0.0.0/8? > I haven't tested this... but I'm 99% certain that you can simply load > them as three separate zones, exactly as you might expect. BIND > should recognize that the zone{} statements for 10.1.3/24 and > 10.1.4/24 are more-specific than what's in 10.0/16 and act > accordingly. Along those same lines, if you happen to have data for > either 10.1.3/24 or 10.1.4/24 inside the 10.0/16 zone file, you should > get an error. You should put in proper delegations for 3.1.10.in-addr.arpa and 4.1.10.in-addr.arpa. Typically you'd do it like this if you're using 10.1.0.0/16: ; in zone 1.10.in-addr.arpa $TTL ... @ IN SOA ... @ IN NS <first server name for 1.10.in-addr.arpa> @ IN NS <second server name for 1.10.in-addr.arpa> 3 IN NS <first server name for 3.1.10.in-addr.arpa> 3 IN NS <second server name for 3.1.10.in-addr.arpa> 4 IN NS <first server name for 4.1.10.in-addr.arpa> 4 IN NS <second server name for 4.1.10.in-addr.arpa> ; rest of content for 1.10.in-addr.arpa or like this if you're using 10.0.0.0/8: ; in zone 10.in-addr.arpa $TTL ... @ IN SOA ... @ IN NS <first server name for 10.in-addr.arpa> @ IN NS <second server name for 10.in-addr.arpa> 3.1 IN NS <first server name for 3.1.10.in-addr.arpa> 3.1 IN NS <second server name for 3.1.10.in-addr.arpa> 4.1 IN NS <first server name for 4.1.10.in-addr.arpa> 4.1 IN NS <second server name for 4.1.10.in-addr.arpa> ; rest of content for 10.in-addr.arpa Sam _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users