Unexpected reverse lookup queries

Kevin Darcy kcd at daimlerchrysler.com
Thu Feb 15 00:46:37 UTC 2001


It's probably just some crappy caching implementation that collapses
CNAME indirection. All they know is that last time they queried
20.222.217.195.in-addr.arpa it was answered (ultimately) by your nameserver. So they
keep going back to your nameserver whenever they need to resolve that PTR.

Why not just go with the flow? Arrange to make yourself a stealth slave for
222.217.195.in-addr.arpa. It's probably a good idea anyway, so that you can resolve
your own reverses even if Pipex's nameservers are unavailable...


- Kevin

Jim Hatfield wrote:

> Hi,
>
> Our ISP, UUNet, has given us the block 195.217.222.16/28.
>
> The nameservers for 222.217.195.in-addr.arpa are ns1-02.dns.pipex.net
> and ns0-02.dns.pipex.net.
>
> Querying them for a reverse lookup of one of our addresses gives, for
> example:
>
> >;; ANSWER SECTION:
> >20.222.217.195.in-addr.arpa.  1D IN CNAME  20.16.222.217.195.in-addr.arpa.
>
> and they delegate 16.222.217.195.in-addr.arpa to our nameservers:
>
> >;; ANSWER SECTION:
> >16.222.217.195.in-addr.arpa.  1D IN NS  nsuu.isltd.insignia.com.
>
> and our nameservers supply the appropriate PTR records:
>
> >;; ANSWER SECTION:
> >20.16.222.217.195.in-addr.arpa.  1D IN PTR  highland.isltd.insignia.com.
>
> All fine. So I cannot understand why nsuu.isltd.insignia.com keeps
> getting queries for names in 222.217.195.in-addr.arpa, e.g.
>
> >Feb 14 15:21:47 highland named[116]: denied query from [210.192.104.66].16643 for
> >"20.222.217.195.in-addr.arpa"
>
> It isn't the same source address every time, there are lots of them.
>
> I just can't work out why this is happening, so I hope it's not
> something horribly obvious.
>
> Jim Hatfield





More information about the bind-users mailing list