Inconsistent reverse lookup problem

[Kevin Darcy]

Where are ns{1,2}.continet.com getting their 65.163.206.in-addr.arpa zone data
from? Verio's ns{0,1,2}.verio.net servers, to which 65.163.206.in-addr.arpa is
delegated, seem to be delegating each address as a separate zone to
ns{1,2}.continet.com, but the delegated nameservers appear to have no zone
definitions at the 4th-octet level, and instead have a monolithic
65.163.206.in-addr.arpa zone with stale/outdated/bogus information in it (i.e.
publishing {b,c,t,u}.ns.verio.net as the nameservers for the zone). I think
continet and Verio need to talk to each other!


- Kevin

Glenn Gillis wrote:

> After changing ISPs recently I've gotten stuck attempting to troubleshoot a
> reverse lookup problem at my site and am having absolutely no luck getting to
> the root of the problem. I hoping someone on the list can spot something I'm
> missing. Essentially, the problem is that outside sites seem to be able to
> successfully perform reverse lookups on our address range, 206.163.65.80/28, but
> from within my network I can't seem to successfully do reverse lookups on part
> of the range. (Yes, the opposite of most reverse lookup problems that show up
> here).
>
> I've verified that both my ISP and a peer at a local university can use nslookup
> under Windows NT 4 to resolve, e.g., 206.163.65.85 and 206.163.65.90 to host
> names. From inside my network, however, 206.163.65.90 resolves properly but
> 206.163.65.85 returns NXDOMAIN. I've tried this using nslookup on a Win 2K pro
> machine and a WinNT4 box, and dig and nslookup on a freeBSD 4.3 box all with the
> same result. In all, 206.163.65.81 through .89 won't resolve while 206.163.65.90
> through .93 will. All of the machines are behind sonicwall soho firewalls but
> only some of them are NATed. I can't find anything in the sonicwall
> configuration that could possibly be messing with DNS resolution.
>
> >From my troubleshooting with dig it appears that the entire range is properly
> delegated to my ISP's servers, ns1.continet.com and ns2.continet.com. Also, I'm
> able to do a zone transfer of 65.163.206.in-addr.arpa from my ISPs DNS servers
> and can clearly see PTR records for all of my addresses, even the ones that I
> can't resolve.
>
> A couple things I've noticed while troubleshooting:
>
> 1) I get some inconsistent results from dig. "dig @ns1.continet.com -x
> 206.163.65.85 ptr" always returns NXDOMAIN, but "dig @ns1.continet.com -x
> 206.163.65.90 ptr" works. "dig @ns1.continet.com -x 206.163.65.85 any" works and
> so does "dig @ns1.continet.com -x 206.163.65.90 any". When I do a zone transfer
> from ns1.continet.com there is clearly a PTR record for 206.163.65.85. Could
> there be some corruption in the zone file screwing up that line? Why on earth
> would this not be affecting people outside of my network?
>
> 2) There seem to be some lame nameservers in the soa for 65.163.206.in-addr.arpa
> returned by ns1.continet.com, but I don't really see how that would be playing a
> role in this particular problem. Or could it?
>
> 3) ns1 seems to running bind 4.9.5 (!), and ns2 8.2.3. While I wouldn't
> personally run 4.9.5 at my site I don't really see how that would be part of
> problem particularly since I get the same response from the one running 8.2.3.
>
> I would happily entertain any suggestions about what could be causing this.
> Thanks, and sorry for the long post.
>
> Glenn
> glenn at elaw.org