Problem with reverse lookup in CIDR delegated domain [file details]

Barry Margolin barmar at alum.mit.edu
Sat Mar 6 04:13:06 UTC 2004


In article <c2b2r3$1st$1 at sf1.isc.org>,
 Kevin Darcy <kcd at daimlerchrysler.com> wrote:

> Barry Margolin wrote:
> 
> >In article <c2b0hk$c7$1 at sf1.isc.org>,
> > Kevin Darcy <kcd at daimlerchrysler.com> wrote:
> >
> >  
> >
> >>Well, you're half right: there is exactly 1 PTR record in the zone, but 
> >>not where anyone would expect to find it (unless they were doing a 
> >>reverse lookup of an address with 5 octets, i.e. 67.116.182.184.186). So 
> >>I'm not sure what the point of this zone is...
> >>    
> >>
> >
> >The CNAME records in the parent zone should cause lookups to be 
> >redirected to this zone.  That's the point of RFC 2317.
> >
> Yes, I see those CNAMEs now. So this is a variant of RFC 2317 with the 
> container zone yet to be fully populated. I guess that would _work_, but 
> I still don't like the choice of container-zone name (the PTR records 
> look to me like reverse records for 5-octet addresses). But then, I've 
> never really cared for the conventions in RFC 2317's examples either. If 
> I had to do "classless delegation" (fortunately all of our external 
> networks are /24 or bigger), I'd probably delegate container zones 
> somewhere under my forward zones...

The name of the container zone is totally arbitrary, and organizations 
have different naming conventions.

At my last company we had a database-driven system for creating our 
named.conf and zone files, and it automatically populated reverse zones.  
So I programmed it to recognize RFC 2317-style zones by them having 
names patterned after the CIDR slash-notation.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***


More information about the bind-users mailing list