nslookup issues on hp-ux

[Jim Reid]

>>>>> "Praveen" == Praveen Kumar Amritaluru <praveen at india.hp.com> writes:

    Praveen> 	It may be true that there are flaws in nslookup.

    Praveen> 	But the fact is that there are lot of people who still
    Praveen> use nslookup and would not be able to migrate from
    Praveen> nslookup to other tools within a short period of time.

Maybe, but they have plenty of warning. The BIND9 version of nslookup
makes it perfectly clear:

	% nslookup 
	Note:  nslookup is deprecated and may be removed from future releases.
	Consider using the `dig' or `host' programs instead.  Run nslookup with
	the `-sil[ent]' option to prevent this message from appearing.

    Praveen> 	It is for these people that the value add of nslookup
    Praveen> will be very useful.

nslookup is utterly useless and broken. The reasons for that have been
explained here many times. Consult the archives for details. nslookup
causes more problems than it solves and deserves to die.

    Praveen> 	If nslookup is not going to be the tool that is going
    Praveen> to do the resolution of hostnames to IP address and
    Praveen> viceversa, then there should be some other tool that will
    Praveen> do this for the users in place of nslookup.

Indeed. For vendors who provide baroque lookup mechanisms and
strategies in the OS, such a tool may be a good idea: especially if it
can tell the user which name subsystem provided the answer. However
that tool should not be called nslookup. (Or the name of any other
existing lookup tool.) nslookup is supposed to be a DNS lookup tool -
albeit a bad and largely useless one. It should not go diving around
other name/address subsystems like NIS or /etc/hosts. That just
creates more potential for confusion. Like "my zone file is OK, but
why does nslookup give me a different answer from what's in the DNS
and what dig reports?"

    Praveen> any reasons why a single tool should not be used and
    Praveen> avoid usage of different tools for querying different
    Praveen> sources in place of a single tool.

Try troubleshooting if the only lookup tool can't tell the user where
it got the answer from. eg A sysadmin looks for problems (or
non-existent problems) in the wrong place because the answer is coming
from somewhere other than the subsystem they're investigating. eg They
thingk the problem is in some NIS map, but it's actually in a zone
file. Or vice versa. Or.... And let's not forget the problems caused
when there is >1 host/name database, like trying to keep them all
consistent. [And if they're consistent, why replicate the same data in
both say DNS and NIS?] Or worse, consider the problems when those
databases are inconsistent or even contradictory.