nslookup give me the reverse

Re: nslookup give me the reverse

From:

Date:

Time:

On 06/06/00 at 18:00, Webmaster wrote:

> > Perhaps the resolver built into OTTool doesn't properly handle this
> > case (called a dangling CNAME). So half the time, it should work
> > fine, and the other half the time, it'll run into a dangling CNAME
> > and fail.
>
> OK, but... is it all of this a problem for me or the zones I admin?
> Can I do something to get the answers before? or because I have a classless
> delegation I can't do nothing.

Because of your classless delegation, you need to use the CNAME record. The
good news is that's not a problem -- it follows a standard way of doing
classless delegations. The 'problems' you've seen are the result of resolvers
that don't follow up on the CNAME to find the PTR record that they're looking
for (in other words, they're doing 'non-recursive' queries). On the other
hand, all of the resolvers that you've given that don't follow the CNAME
aren't necessarily supposed to. In other words, OTTool, AGNetTools and
PINetTools are diagnostic tools that are intended to be used for analyzing DNS
records. They assume that the user is following along with the records they
return, and that the user will perform additional queries where necessary.
With some of them, you may even be able to tell them to do 'recursive'
queries. For every day use, say a mail server doing a reverse look-up to
verify a domain name, the 'client' will send a query to whatever name server
it is configured to use. In that case the name server will perform a recursive
look-up, find the proper PTR record, and all will be well. The bottom line is
that your set-up is fine and shouldn't cause undue problems.

> Applications used quering for 195.53.92.111:
> supposed correct answer = www.eps.es
>
> OTTool =
> 111.64.92.53.195.in-addr.arpa.
> Bad answer in my point of view

OTTool is not following the CNAME to get the PTR record you're looking for.

> AGNetTools =
> 111.64.92.53.195.in-addr.arpa.
> Bad answer in my point of view

Like OTTool, AGNetTools is not following the CNAME.

> WhatRoute =
> 111.64.92.53.195.in-addr.arpa. 172800 IN PTR www.eps.es.
> I dont understand this kind of answer

This is the result you're looking for. The PTR record is the answer to your
'reverse lookup,' giving the domain name 'www.eps.es.'

> nslookup =
> name: www.eps.es
> address: 195.53.92.111
> aliases: 111.64.92.53.195.in-addr.arpa. (this line never
> was in my queries with nslookup -Win NT command-)
> Good answer in my point of view

Actually the same result as WhatRoute. Nslookup simply rephrases the answer
into a form that is more 'human-readable.' The 'aliases' line reflects the
CNAME record.

> PINetTools =
> <nslookup:111.92.53.195.in-addr.arpa/*>
> Non-authoritative answer:
> 111.92.53.195.in-addr.arpa CNAME 169857 111.64.92.53.195.in-addr.arpa
> Authority:
> 53.195.in-addr.arpa NS 327955 minerva.ttd.net 194.179.1.100
> 53.195.in-addr.arpa NS 327955 artemis.ttd.net 194.179.1.101
> 53.195.in-addr.arpa NS 327955 ns.ripe.net 193.0.0.193
> NSLookup normal completion.
> I dont understand this kind of answer

PINetTools is not following the CNAME, so it doesn't return the PTR record.

> <nslookup:111.92.53.195.in-addr.arpa/PTR>
> Non-authoritative answer:
> 111.92.53.195.in-addr.arpa CNAME 169668 111.64.92.53.195.in-addr.arpa
> 111.64.92.53.195.in-addr.arpa PTR 172800 www.eps.es
> Authority:
> 64.92.53.195.in-addr.arpa NS 172800 osiris.eps.es 195.53.92.99
> 64.92.53.195.in-addr.arpa NS 172800 artemis.ttd.net 194.179.1.101
> NSLookup normal completion.
> I dont understand this kind of answer

This is the result you're looking for, as it includes the PTR, along with all
other records used to find it. This is the most complete answer of all the
examples you've given.

Christopher Bort

Sales:
888/4-DPOINT

Support:
858/452-3696