nslookup issues on hp-ux

[Praveen Kumar Amritaluru]

> 
> Praveen Kumar Amritaluru wrote:
> 
> > >
> > > At 06:33 22.02.2001 -0800, you wrote:
> > >
> > >
> > > >Okay, now I'm really confused. I thought nslookup called resolver
> > > >routines, which are supposed to check /etc/nsswitch.conf. The libbind.a
> > > >looks like it compiles its own versions of the resolver routines, then
> > > >gets linked into nslookup. So it is not using the native resolver routines
> > > >from HP-UX, which, according to the man pages, go to nsswitch.conf to see
> > > >where to resolve from. Also, both texts I consulted ("DNS and BIND, 3rd
> > > >Ed." and "(The Concise Guide to) DNS and BIND") describe this resolver
> > > >behavior, that nslookup uses the resolver to find which service to use
> > > >(files, DNS or NIS). I'm very confused at this point and don't know what
> > > >to believe...
> >
> >         Still  nslookup  that  comes up with HP's  distribution  will be
> >         following /etc/nsswitch.conf file. If you want the latest version
> >         of nslookup, then try downloading BIND 8.1.2 on HP-UX available
> >         at http://www.software.hp.com.
> >
> >         But  the  public   domain   nslookup   code  does  not  use  the
> >         /etc/nsswitch.conf file and more over the nslookup is built from
> >         static library  libbind.a which does not read the  nsswitch.conf
> >         file.  nslookup  that you were using  earlier  should be working
> >         well with new version of BIND.
> >
> >         Public domain  nslookup code should be doing this  modification,
> >         as IP add.  -  hostname  information  is stored not just in DNS,
> >         but also in FILES & NIS.
> 
> I disagree vehemently. nslookup is a *DNS-specific* lookup tool. It comes with the
> BIND distribution; in fact, its code was ripped out of an early BIND codebase and
> made standalone. The "ns" in "nslookup" is echoed from "DNS". Nobody ever intended
> it to be the all-singing, all-dancing, generic lookup tool for all naming sources
> in the known universe, and in fact it would be horrible for that, since it only
> understands a DNS or DNS-like naming hierarchy. It would be totally hopeless, for
> instance, trying to navigate X.500, Active Directory or even NetInfo.
> 
> Besides, the more useful you make nslookup, the longer it lives. It should have
> already been buried by now, because of all of its quirks and flaws.
> 
> 
> - Kevin
> 

	I dont want to get into discussion on whether nslookup should be
	obsoleted or not as there was already a big  discussion  on this
	mailing-list over this issue.

	It may be true that there are flaws in nslookup.

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

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

	It may be true that nslookup was a tool that got developed  from
	BIND code base and was not  intended to be all  singing....  But
	it is also true that  people will still need a tool to query for
	hostname  resolution  irrespective  of  whether  they are  using
	DNS/FILES/NIS etc...

	If nslookup  is not going to be the tool that is going to do the
	resolution of hostnames to IP address and viceversa,  then there
	should  be some  other  tool that  will do this for the users in
	place of  nslookup.  I dont see any  reasons  why a single  tool
	should  not be used  and  avoid  usage of  different  tools  for
	querying different sources in place of a single tool.

	If nslookup can be modified  without  much  complexity  to query
	other databases then the same can be used.


-Praveen

*******************************************************************************

	These views are mine only and not related to HP

*******************************************************************************