Problems w/ Reverse DNS and RFC 2317

[Joseph S D Yao]

On Wed, May 17, 2000 at 04:30:57PM -0700, Chris McCluskey wrote:
...
> 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. 

This has nothing to do with whether you further subnet your subnet.  In
fact, you already have a fractional "class C" [/24] network.  You need
RFC 2317.

> 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?

1) Who knows?  2) Absolutely.  3) There is no such thing as doing it
unilaterally.

...
> 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!?

In each zone file, you must always have NS records for all domains in
that zone.  Otherwise, once a remote name server has gotten the
"authoritative" information on your zone, that authoritative
information will say: "THIS ZONE HAS  N O  NAME SERVERS."  Bad news.

If the zone has any child domains [as these do], they also must have NS
records for the zones that contain the child domains.  These NS records
must agree with those in those domains' zone files.

This is all in The Book [DNS and BIND 3rd Ed., Albitz & Liu,
O'Reilly & Assoc.].

> 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? ...

In the 64_26.137.7.12.in-addr.arpa zone file, you have entries:

81.137.7.12.in-addr.arpa.		PTR	expression1-1-0.expression.edu.
83.137.7.12.in-addr.arpa.		PTR	gw1.expression.edu.
100.137.7.12.in-addr.arpa.		PTR	ns1.expression.edu.

NONE OF THESE is in the zone for which the zone file is created!  That
zone is "64_26.137.7.12.in-addr.arpa".  These are not in those zones.

You must either do the following [deprecated by me just because it's
clunky and may lead to errors]:

81.64_26.137.7.12.in-addr.arpa.		PTR	expression1-1-0.expression.edu.
83.64_26.137.7.12.in-addr.arpa.		PTR	gw1.expression.edu.
100.64_26.137.7.12.in-addr.arpa.	PTR	ns1.expression.edu.

or [better, because it FORCES them to be in the right zone] the
following:

81		PTR	expression1-1-0.expression.edu.
83		PTR	gw1.expression.edu.
100		PTR	ns1.expression.edu.

Then, once you look up [e.g.] 12.7.137.81, it will look in the
137.7.12.in-addr.arpa domain, and find that 81.137.7.12.in-addr.arpa
has a CNAME of 81.64_26.137.7.12.in-addr.arpa.  It will look in the
64_26.137.7.12.in-addr.arpa domain, and find that
81.64_26.137.7.12.in-addr.arpa is a PTR to
expression1-1-0.expression.edu.  And that is the value [along with the
other interesting tidbits it learned along the way] that it will
return.

Capish?

-- 
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.