Problems w/ Reverse DNS and RFC 2317
Mark.Andrews at nominum.com
Mark.Andrews at nominum.com
Thu May 18 01:25:21 UTC 2000
>
> 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).
Don't you mean 12.7.137.64/26? The 64 is *not* redundent
as it specifies the upper 2 bits. The other 3 nets that
have a /26 under 12.7.137 are 12.7.137.0/26, 12.7.137.228/26
and 12.7.137.192/26.
Without reading the text below I would have assumed you
ment 12.7.137.0/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.
No. It is best practice for /25-/32 CIDR blocks or for
non-CIDR blocks. For blocks larger than /25 (/0-/24) you
use traditional delegation.
>
> 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,
Why don't you just ask them? You are their customer after all.
> 2) Do I need to implement 2317 (if yes, please see below), and 3) Do we
> both need to be implementing RFC2317?
Both of you need to implement your parts RFC 2317.
>
> 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!?
The documentation talks about delegating sub blocks. All zones
have SOA and NS records at their top.
Also I would *not* call the zone 64_26.137.7.12.in-addr.arpa as
there are broken resolvers that will reject that name. I would
use "64-127.137.7.12.in-addr.arpa" instead as this works with
these broken resolvers. It is also a naming scheme which copes
with non CIDR blocks (e.g. you have 9 servers on a switch
co-located at with other servers on the same subnet).
>
> 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.
>
>
>
> >From syslog (the forwarding address of 0.0.0.0, is an artifact of using
> GCC on a SGI machine):
>
> May 16 20:52:41 5D:earth named[240]: reloading nameserver
> May 16 20:52:41 4D:earth named[240]: Zone "137.7.12.in-addr.arpa" (file 12.7.
> 137): no NS RRs found at zone top
> May 16 20:52:41 4D:earth named[240]: master zone "137.7.12.in-addr.arpa" (IN)
> rejected due to errors (serial 2000051604)
> May 16 20:52:41 6D:earth named[240]: 12.7.137.64_26:14: data "81.137.7.12.in-
> addr.arpa" outside zone "64_26.137.7.12.in-addr.arpa" (ignored)
> May 16 20:52:41 6D:earth named[240]: 12.7.137.64_26:15: data "83.137.7.12.in-
> addr.arpa" outside zone "64_26.137.7.12.in-addr.arpa" (ignored)
> May 16 20:52:41 6D:earth named[240]: 12.7.137.64_26:16: data "100.137.7.12.in
> -addr.arpa" outside zone "64_26.137.7.12.in-addr.arpa" (ignored)
> May 16 20:52:41 6D:earth named[240]: master zone "64_26.137.7.12.in-addr.arpa
> " (IN) loaded (serial 2000051603)
> May 16 20:52:41 6D:earth named[240]: Forwarding source address is [0.0.0.0].1
> 128
> May 16 20:52:41 5D:earth named[240]: Ready to answer queries.
> May 16 20:54:12 5D:earth named[240]: reloading nameserver
> May 16 20:54:12 6D:earth named[240]: master zone "137.7.12.in-addr.arpa" (IN)
> loaded (serial 2000051605)
> May 16 20:54:12 6D:earth named[240]: Forwarding source address is [0.0.0.0].1
> 129
> May 16 20:54:12 5D:earth named[240]: Ready to answer queries.
> May 16 20:54:43 5D:earth named[240]: reloading nameserver
> May 16 20:54:43 6D:earth named[240]: 12.7.137.64_26:14: data "81.137.7.12.in-
> addr.arpa" outside zone "64_26.137.7.12.in-addr.arpa" (ignored)
> May 16 20:54:43 6D:earth named[240]: 12.7.137.64_26:15: data "83.137.7.12.in-
> addr.arpa" outside zone "64_26.137.7.12.in-addr.arpa" (ignored)
> May 16 20:54:43 6D:earth named[240]: 12.7.137.64_26:16: data "100.137.7.12.in
> -addr.arpa" outside zone "64_26.137.7.12.in-addr.arpa" (ignored)
> May 16 20:54:43 6D:earth named[240]: master zone "64_26.137.7.12.in-addr.arpa
> " (IN) loaded (serial 2000051604)
> May 16 20:54:44 6D:earth named[240]: Forwarding source address is [0.0.0.0].1
> 130
> May 16 20:54:44 5D:earth named[240]: Ready to answer queries.
>
>
> File 12.7.137, master for the 137.7.12.in-addr.arpa domain:
>
> $TTL 86400
> 137.7.12.in-addr.arpa. IN SOA ns1.expression.edu. root.ns1.expression.edu. (
> 2000051605 ;Serial
> 10800 ;Refresh
> 3600 ;Retry
> 604800 ;Expire
> 86400 ;TTL
> )
>
>
> ; Name Servers
> 137.7.12.in-addr.arpa. NS ns1.expression.edu.
> 64_26.137.7.12.in-addr.arpa. NS ns1.expression.edu.
> ;Add additional AT and T servers here
>
>
> 81 CNAME 81.64_26.137.7.12.in-addr.arpa.
> 83 CNAME 83.64_26.137.7.12.in-addr.arpa.
> 100 CNAME 100.64_26.137.7.12.in-addr.arpa.
>
This looks ok conceptually. The CNAMES should cover the
entire CIDR block and I would change the child zone name
as discussed above. In the end this will be maintained by
AT&T any you should be a (stealth) slave so that local
lookups work when the external link is down.
>
> File 12.7.137.64_26, master for the 64_26.137.7.12.in-addr.arpa domain:
>
>
> $TTL 86400
> 64_26.137.7.12.in-addr.arpa. IN SOA ns1.expression.edu. root.ns1.expression.e
> du. (
> 2000051604 ;Serial
> 10800 ;Refresh
> 3600 ;Retry
> 604800 ;Expire
> 86400 ;TTL
> )
>
> ; Name Servers
> 64_26.137.7.12.in-addr.arpa. NS ns1.expression.edu.
> ;Add additional AT and T servers here
This comment is wrong.
>
> 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.
These should be
81.64_26.137.7.12.in-addr.arpa. PTR expression1-1-0.expression.edu.
83.164_26.37.7.12.in-addr.arpa. PTR gw1.expression.edu.
100.164_26.37.7.12.in-addr.arpa. PTR ns1.expression.edu.
or better still change the whole zone to
$TTL 86400
@ SOA ns1.expression.edu. root.ns1.expression.edu. (
2000051604 ;Serial
10800 ;Refresh
3600 ;Retry
604800 ;Expire
86400 ) ;TTL
NS ns1.expression.edu.
81 PTR expression1-1-0.expression.edu.
83 PTR gw1.expression.edu.
100 PTR ns1.expression.edu.
and let the server qualify all the owner names. The wrong
owner names was the reason for the out of zone messages.
>
>
> The /etc/named.conf file, if needed:
>
> options {
> directory "/var/named";
> };
>
> zone "." in {
> type hint;
> file "root.cache";
> };
>
> zone "localhost" in {
> type master;
> file "localhost";
> };
>
> zone "0.0.127.in-addr.arpa" in {
> type master;
> file "127.0.0";
> };
>
> zone "expression.edu" in {
> type master;
> file "expression.edu";
> allow-query { any; };
> # Allow transfers from the following hosts
> # allow-transfer { uuu.vvv.www.xxx; };
> };
>
> zone "137.7.12.in-addr.arpa" in {
> type master;
> file "12.7.137";
> allow-query { any; };
> # Allow transfers from the following hosts
> # allow-transfer { uuu.vvv.www.xxx; };
> };
>
> zone "64_26137.7.12.in-addr.arpa" in {
zone "64_26.137.7.12.in-addr.arpa" in {
> type master;
> file "12.7.137.64_26";
> allow-query { any; };
> # Allow transfers from the following hosts
> # allow-transfer { uuu.vvv.www.xxx; };
> };
Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews at nominum.com
More information about the bind-users
mailing list