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