nslookup issues on hp-ux

Kevin Darcy kcd at daimlerchrysler.com
Thu Feb 22 22:27:47 UTC 2001


Just set up the private IP addresses in DNS. If you for some reason need to limit
the visibility of those names, use allow-query ACLs and/or only define the
relevant zones on those servers which should have access to them.

IMO, /etc/hosts files are only for bootstrapping. HP's hack to nslookup nauseates
me. (As if nslookup weren't confusing enough as it is...)


- Kevin

medaglia at nyctea.blackcat.com wrote:

> You're right, I did answer my own question. My head hurts so thanks for
> pointing that out!!  ;-)  I guess my question now is, is there a way to
> force the BIND nslookup to use the native system libraries. Dig rules for
> doing lookups and troubleshooting, but I have a whole user community that
> uses nslookup and expects it to check files first, then DNS. We do this
> because we have customer private IP addresses in our hosts files on
> specific servers. I can definitely continue using the version that came
> with HP, I just wanted to use the latest and greatest from the BIND
> distribution so we can stay up to date. That's why it would be cool to
> have nslookup use the native routines.
>
> Speaking of private IPs, is anyone using subdomains to address this
> problem, or is it best to just keep it in the /etc/hosts files on
> individual machines?
>
> Thanks Bill and Mark for the responses!! I feel more sane now...
>
> Chris
>
> On Thu, 22 Feb 2001, Bill Larson wrote:
>
> > You identified your own answer to your problem.
> >
> > nslookup in BIND-8 gets linked against the libbind.a and the BIND
> > resolver libraries.  This is NOT the system libraries!  Any
> > modification of the system libraries, by yourself or HP, will not get
> > reflected in the operation of nslookup.
> >
> > This difference between the resolver library that nslookup uses
> > compared to the library that is provided by the system CAN cause
> > differences in operation.  One example is that the BIND nslookup does
> > not use /etc/nsswitch.conf to determine HOW to resolve names.  On
> > old Sun systems, I have seen other differences too.
> >
> > HP uses it's "nslookup" tool extensively in it's SAM, system
> > administration tool.  Because of this, I would suggest that you do NOT
> > install the BIND version of nslookup on an HP system.
> >
> > If you are trying to troubleshoot a DNS problem, a symple solution is
> > to avoid using nslookup and move to using dig.  dig seems to operate at
> > a "lower" level of the DNS protocol.  It responds more correctly to DNS
> > queries, without involving system level resolver issues, such as
> > /etc/nsswitch.conf.
> >
> > Bill Larson
> >
> > > 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...
> >





More information about the bind-users mailing list