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
