Problems w/ Reverse DNS and RFC 2317

[Chris McCluskey]

Hello,

I'm currently having trouble setting up the reverse DNS lookups for my
subdomain. I'm sure that these issues have come up in this list before,
but a casual search didn't turn anything up.

So here it goes. 

I'm currently running a subnetwork off of an At&T subnet
(12.7.137/26). The arin records do point to my DNS servers (or soon will
anyway ;). The problem I'm having relates back to RFC 2317. I do not need
to further subnet my network as it currently stands, however, based upon
2317 it was the best practice to use the CNAME method for ANY classless
subnet block. 

The way it is currently set up, my server is authorative for the
137.7.12.in-addr.arpa domain. This is currently wokring well, but I'm
concerned that when AT&T starts the secondary name service that there
might be problems (receiving an arpa zone from the zone transfer that
would be invalid -- receiving an in-addr.arpa zone file from me which 
duplicates one already in the database). So one of the questions I have
is: 1) Is AT&T likely to be running the method as defined by RFC2317,
2) Do I need to implement 2317 (if yes, please see below), and 3) Do we
both need to be implementing RFC2317?


If I do need to implement RFC2317 for my DNS servers, I have an additional
set of problems. The only clue I have about the errors are contained in
the syslog excerpt below. The BIND version is 8.2.2p4.

For some reason, if I do not put NS records for both the
137.7.12.in-addr.arpa and 64_26.137.12.in-addr.arpa zones in the
12.7.137 zone file I get a "no NS RR records found at zone top
message". I'm not sure why. According to all the documentation I would
only need the line for 64_26.137.7.12.in-addr.arpa!?

Also from the syslog messages, all of the reverse mapped addresses (as
contained in the 64_26.137.7.12.in-addr.arpa zone file) are said to be
out of the 12.7.137 zone. So are they out of zone for the 12.7.137 zone
file, 12.7.137.64_26 file, or both? How is this fixed? I can see how the
PTR records are only valid for the 12.7.137.64_26 zone file, but how do I
make them peacefully co-exist with the orginal 12.7.137 zone?! If this is
supposed be be done only with two different servers, one which
(would typically be authorative for the entire "class") passes on
delegation to the subnetwork servers and the other which contains all of
the PTR records (as pointed to by the "classful" server) then this makes
sense. If this is supposed to be done on a single DNS server then I think 
I missed a step along the way. 

Thank you for the help.