Assistance with reverse lookup zone

[Frank Pikelner]

On Fri, 2009-06-12 at 11:42 +1000, Mark Andrews wrote:
> In message <B86F8BCEEED5184CA225E0CC10FF61163EC03A at bdc03srv04.bdc.int>, "Frank 
> Pikelner" writes:

> > Every now and then we get a bounce on emails that are sent through one =
> > of our mails servers located on 64.187.3.170. The bounce messages look =
> > as follows and appear to indicate that our reverse zone is missing a =
> > record, though the record is there and resolves through nslookup. The =
> > ISP delegates a number of IP addresses from the zone back to us (16 IP =
> > addresses). So my guess is that our zone file needs to be rewritten or =
> > there may be something else I'm missing.
> > 
> > 
> > <first_last at some_domain.com>: host mx.some_domain.com[xxx.xx.xx.xx] =
> > said: 450 4.7.1 Client
> >     host rejected: cannot find your hostname, [64.187.3.170] (in reply =
> > to RCPT
> >     TO command)
> > 
> > 
> > Performing a manual reverse lookup correctly displays the correct name =
> > for 170.3.187.64.in-addr.arpa. Our zone file looks as follows (other =
> > records removed):
> 
> 	ns1.blue-dot.ca is NOT configured to serve
> 	162-27.3.187.64.in-addr.arpa.  It should be so configured.
> 
> 	Mark
> 
> 162-27.3.187.64.in-addr.arpa. 86400 IN  NS      ns3.blue-dot.ca.
> 162-27.3.187.64.in-addr.arpa. 86400 IN  NS      ns1.blue-dot.ca.
> 162-27.3.187.64.in-addr.arpa. 86400 IN  NS      ns2.blue-dot.ca.
> ;; Received 115 bytes from 209.135.99.3#53(ns2.toroon.grouptelecom.net) in 249 ms
> 
> 3.187.64.in-addr.arpa.  1800    IN      SOA     ns1.blue-dot.ca. dnsadmin.ns1.blue-dot.ca. 2009011401 1800 900 604800 1800
> ;; Received 110 bytes from 64.187.3.170#53(ns3.blue-dot.ca) in 679 ms
> 

Thank you for everyone's assistance. I have updated the zone files.
After the updates and restarting BIND, I run "dig +trace ptr
170.3.187.64.in-addr.arpa" and the result stops just prior to getting to
my DNS server and correctly resolving the name of the IP address. I'm
new to dig and do not know whether this is correct for an RFC2317 zone
delegation or whether the trace should be completing at my servers and
resolving the name. My guess is there must be something still incorrect
on my end. 

Though, using NSLOOKUP against opendns servers for
170.3.187.64.in-addr.arpa does resolve the name correctly.


NAMED.CONF has the zone defined as follows:

zone "162-27.3.187.64.in-addr.arpa" IN {
        type master;
        file "64_187_3_162-27.rev";
};


The zone file looks as follows:

$ORIGIN .
$TTL 86400      ; 1 day
162-27.3.187.64.in-addr.arpa.   IN SOA  ns1.blue-dot.ca.
dnsadmin.ns1.blue-dot.ca. (
                                2009051202 ; serial
                                1800       ; refresh (30 minutes)
                                900        ; retry (15 minutes)
                                604800     ; expire (1 week)
                                1800       ; minimum (30 minutes)
                                )
                        NS      ns1.blue-dot.ca.
                        NS      ns2.blue-dot.ca.
                        NS      ns3.blue-dot.ca.
$ORIGIN 162-27.3.187.64.in-addr.arpa.
170                     PTR     smtp3.netcraftcommunications.com.