Parent and Child subzones with overlapping reverse address space
Kevin Darcy
kcd at daimlerchrysler.com
Tue Dec 16 01:45:23 UTC 2003
John Tobias wrote:
>Dear BIND gurus:
>
>I have a problem that I'm hoping that you can help with. I have a Parent
>and a Child zone that are obviously authoritative for different forward
>zones, but share IP address space (e.g. systems in both the parent and
>child zones could have a 10.20.4.x address). In my configuration the
>servers with the child zones forward to the parent servers for zones
>they are not authoritative for.
>
>My problem is that this arrangement is causing me some problems in
>providing complete reverse zone mappings - i.e. both the parent and
>child servers may both be authoritative for 4.20.10.IN-ADDR.arpa, and
>since only approx. 1/2 the addresses may exist in any one server,
>depending on which server is queried, only 1/2 the addresses are
>available for reverse lookups. In looking for a solution, I'm wondering
>if it's possible that using the "forward first" option on the zone
>statements may provide a workaround. Any ideas?
>
No, forwarding isn't going to help you here. If a nameserver is
authoritative for a zone, it never forwards for anything in the zone (it
may, however, forward for subzones). That's part of what being
"authoritative" means. If I understand your description of the
situation, multiple servers are currently defined as master for the
reverse zone(s) in question, so they'll never forward for queries in the
zone(s). Moreover, if you want multiple nameservers controlling reverse
lookups in a /24 range, then it is not possible to break out subzones of
that zone, short of delegating each address as a separate zone, since
the reverse DNS namespace is based on octet boundaries.
A general solution to such smaller-than-/24-delegation challenges is to
have one server be master and to install aliases (CNAMEs) wherever PTRs
would normally be found in that zone, for addresses that are under the
control of another server. The aliases can point to names in any zone --
let's call it the "container zone" -- that is under the control of the
other server and where the actual PTRs reside. The container zone is not
even limited to the in-addr.arpa tree. See RFC 2317 for a general
outline of how this works.
The downside of this so-called "classless in-addr delegation" is that
your maintenance procedures/processes need to change, since all of the
servers besides the master now need to maintain PTRs in a different
place -- the container zone -- than they would normally expect to find
them. If you can group the addresses into contiguous ranges and adopt a
consistent naming convention for the PTR names, then the $GENERATE
zonefile directive might come in pretty handy...
- Kevin
More information about the bind-users
mailing list