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