Parent and Child subzones with overlapping reverse address space

Kevin Darcy kcd at daimlerchrysler.com
Wed Dec 17 01:49:39 UTC 2003


"Forward first" is opportunistic -- try forwarding, but if that doesn't 
work, fall back to "iterative" (non-recursive) resolution. "Forward 
only", on the other hand, uses forwarding exclusively, and if that 
doesn't work, the query fails.

"Forward first" is only appropriate when you're using forwarding solely 
as a performance enhancement. "Forward only" is what you'd normally use 
if you need to get around some sort of connectivity problem (e.g. a 
firewall between your private intranet and the Public Internet).

- Kevin

John Tobias wrote:

>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