PTR record handling in a subnetted network

[Bob Vance]

Thanks.
Interesting.

On my little home net (16 nodes), I actually did this on the internal
side, even
though I've got the full /24 :)
A couple of $GENERATEs in the

    1.168.192.in-addr.arpa.

zone, one for my  static range and one for the dynamic-update DHCP range
and now
I never have to touch that zone, again :)
The "static" $GENERATE points into the normal forward zone, "vance.",
while the "dynamic" one points into "dynamic.vance.", to which both the
forward and the reverse  dynamic updates go.

I do have the overhead of the extra lookup for the reverse lookup plus a
few
unsatisfied CNAMEs (until I add more nodes :), all of which, of course,
amounts
to nothing in my environment.


-------------------------------------------------
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: Jim Reid [mailto:jim at rfc1035.com]
Sent: Tuesday, March 06, 2001 3:59 PM
To: bobvance at alumni.caltech.edu
Cc: bind-users at isc.org
Subject: Re: PTR record handling in a subnetted network


>>>>> "Bob" == Bob Vance <bobvance at alumni.caltech.edu> writes:

    Bob> Personally, and as I have said here before, I would prefer to
    Bob> have the ISP's CNAMEs simply point into my forward zone.

    Bob> At least 2 benefits: . no new zone delegations nor NS RRs for
    Bob> anybody to worry about, . the PTRs can sit right next to
    Bob> their corresponding forward RR.

    Bob> No one has yet given me a reason for *not* doing that.

Some people already do that. For instance take a look at
6.242.6.62.in-addr.arpa.