Parent and Child subzones with overlapping reverse address space

John Tobias JTobias at gilead.com
Wed Dec 17 01:18:40 UTC 2003


Kevin -

Thanks for the complete and clear explanation. I am still confused about
some things: can you explain the operation of "forward first, and
"forward-only"?

Thanks.

~~~~~~~~~~~~~~~~
John Tobias
Corporate Infrastructure
Gilead Sciences

-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
Behalf Of Kevin Darcy
Sent: Monday, December 15, 2003 5:45 PM
To: comp-protocols-dns-bind at isc.org
Subject: Re: Parent and Child subzones with overlapping reverse address
space

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=20
authoritative for a zone, it never forwards for anything in the zone (it

may, however, forward for subzones). That's part of what being=20
"authoritative" means. If I understand your description of the=20
situation, multiple servers are currently defined as master for the=20
reverse zone(s) in question, so they'll never forward for queries in the

zone(s). Moreover, if you want multiple nameservers controlling reverse=20
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=20
the reverse DNS namespace is based on octet boundaries.

A general solution to such smaller-than-/24-delegation challenges is to=20
have one server be master and to install aliases (CNAMEs) wherever PTRs=20
would normally be found in that zone, for addresses that are under the=20
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=20
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=20
outline of how this works.

The downside of this so-called "classless in-addr delegation" is that=20
your maintenance procedures/processes need to change, since all of the=20
servers besides the master now need to maintain PTRs in a different=20
place -- the container zone -- than they would normally expect to find=20
them. If you can group the addresses into contiguous ranges and adopt a=20
consistent naming convention for the PTR names, then the $GENERATE=20
zonefile directive might come in pretty handy...

- Kevin








More information about the bind-users mailing list