PTR record handling in a subnetted network

Kevin Darcy kcd at daimlerchrysler.com
Tue Mar 6 04:06:43 UTC 2001


I've been promulgating it for a while.

Old habits seem to die hard. Many folks appear to be locked into the
mindset that PTR records *must* be owned by an in-addr.arpa name. Or, they
are reading RFC 2317's *example* naming conventions as mandates, not
realizing that the scheme -- which basically just boils down to "hey, use
aliases to delegate control" -- is actually a lot more flexible than that
and aliasing into an already-existing "forward" zone could save some
unnecessary delegations...

If folks are *really* insistent on segregating their PTR records from other
types of records, they could always just create a subzone for the purpose,
e.g. rev.example.com. Or, if they foresee expanding to multiple address
ranges, perhaps extranet1.example.com, extranet2.example.com etc.

I should point out, however, that this may all sound rather uninformed
and/or hypocritical coming from me. I've never actually had to do DNS for a
sub-/24 address range in the real world; only in testbeds. So folks should
take such recommendations with a grain of salt.


- Kevin

Bob Vance wrote:

> >That's because it's allowed under the sections I quoted.
>
> I understand and noticed that :)
>
> My question was why anyone would want to go to the trouble of
>     . the ISP's delegating another zone
> and . requiring another zone for the end-user to manage
>
> All the discussions seem to focus on this delegation some sub-zone of
> z.y.x.in-addr.arpa. , rather than simply using CNAMEs into the
> already-existing forward zone.
>
> What I was saying is that the latter seems to me to be a better and
> simpler solution and no one has said differently or given any drawbacks
> to this solution.  If the advantages are there and there aren't any
> drawbacks, then why isn't this solution promulgated more on this list?
>
> -------------------------------------------------
> Tks        | <mailto:BVance at sbm.com>
> BV         | <mailto:BobVance at alumni.caltech.edu>
> Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
> Vox 770-623-3430           11455 Lakefield Dr.
> Fax 770-623-3429           Duluth, GA 30097-1511
> =================================================
>
> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org]On
> Behalf Of Joseph S D Yao
> Sent: Monday, March 05, 2001 7:02 PM
> To: bind-users at isc.org
> Subject: Re: PTR record handling in a subnetted network
>
> On Mon, Mar 05, 2001 at 06:20:02PM -0500, Bob Vance wrote:
> > Personally, and as I have said here before, I would prefer to have the
> > ISP's CNAMEs simply point into my forward zone.
> >
> > At least 2 benefits:
> >  . no new zone delegations nor NS RRs for anybody to worry about,
> >  . the PTRs can sit right next to their corresponding forward RR.
> >
> > No one has yet given me a reason for *not* doing that.
>
> That's because it's allowed under the sections I quoted.
>
> -----------------------------------------------------------------------
>    This way you can actually end up with the name->address and the
>    (pointed-to) address->name mapping data in the same zone file - some
>    may view this as an added bonus as no separate set of secondaries for
>    the reverse zone is required.  Do however note that the traversal via
>    the IN-ADDR.ARPA tree will still be done, so the CNAME records
>    inserted there need to point in the right direction for this to work.
> -----------------------------------------------------------------------
>
> Sorry, they already thought of that.  ;-]
>
> --
> Joe Yao                         jsdy at cospo.osis.gov - Joseph S. D. Yao
> COSPO/OSIS Computer Support                                     EMT-B
> -----------------------------------------------------------------------
> This message is not an official statement of COSPO policies.





More information about the bind-users mailing list