Problem with nslookup

[Anders Gullberg]

We have problems with long respons time with nslookup. It could take up to 1min 30sec to get response. Most of the time it response normally. We tried to move the specific host into /etc/hosts but the response time didnt change.
/etc/nsswitch.conf for hosts are:
hosts: files [NOTFOUND=continue UNAVAIL=continue] dns [NOTFOUND=return UNAVAIL=continue TRYAGAIN=return]

With the adress in /etc/hosts the respons should be really quick its just locally.

Any one have an idea??

[G. Vrijhoeven]

Hi,

I agree, when the servername is matched in /etc/hosts the response should be quick ( mind short names vs. fqdn). When not matched it will go to the first nameserver in /etc/resolv.conf. When this server does not responce you will get a timeout before it will go to the second server.

Regards,

Gideon

It is quite a long line in the nsswitch.conf
Why not just
host: files [NOTFOUND=continue] dns

[twang]

edit your nsswitch.conf:
---------------
hosts: files [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=continue] dns [NOTFOUND=return UNAVAIL=continue TRYAGAIN=return]
aliases: files
---------------

Hope it helps.

[Anders Gullberg]

Yes we could have a shorter entry for hosts but when files is first it shouldnt matter how long it is..
The adress we need to resolve is a print server. we do 400 - 600 printjobs/day and when we not could resolve the printserver the print que goes down.

[Sยภเl Kย๓คг]

If Dns is configured,can u try removing that temporarly.
regards
SK

[Jeroen Peereboom]

Indeed looking up in /etc/hosts should be quick.

You've shown your nssiwtch.conf, but what is your resolv.conf? I'm thinking of domain names and search lists.

Do you specify which DNS server to use when you use nslookup?

Is the 'problem' host on the same domain as other 'non-problem' hosts?

JP.

[Anders Gullberg]

Hi all and thanks for the respons!
I dare not dissable dns.

Our resolve.conf:
#
search xx.xxxx.xxx xx.xxxx.xxx
nameserver xx.xx.xx.xx
nameserver xx.xx.xx.xx

When i use nslookup just:
#nslookup host/ip


even that we just use files in nsswitch.conf we get:

*** Can't find server name for address xx.xx.xx.xx: Timed out

[Geoff Wild]

OH HP-UX, you can also set the following in resolv.conf:


retrans 2500
retry 2

retrans

Retransmission timeout. It is interpreted during
the res_init() (see resolver(3N)) call. It has
higher precedence than setting it through the
set_resfeild() (see resolver(3N)) API and lower
precedence than setting it through the RES_RETRANS
(see resolver(3N)) environment variable. Whenever
an invalid value is specified for retrans, a
message is flagged in syslog. The default value
is 5000 milliseconds.

retry

Number of retries. This is interpreted during the
res_init() (see resolver(3N)) call. It has higher
precedence than setting it through the
set_resfeild() (see resolver(3N)) API and lower
precedence than setting it through the RES_RETRY
(see resolver(3N)) environment variable. Whenever
an invalid value is specified for retry, a message
is flagged in syslog. The default value is 4.


That will speed up any delays going from 1 nameserver to another - unfortunately, Windows does a better job - if it can't get to the first one, it goes to the second - if successful, it's next query will automatically go to the second. In unix, this is not the case - we will always try the nameservers in order based on resolv.conf.

Rgds...Geoff

[Anders Gullberg]

The problem is why the response time is so long sometimes even that we have files first in the /etc/nsswitch.conf???
Does nslookup use resolv.conf anyway somehow???

[Ralph Grothe]

How is your routing to the first DNS server in line?

You can verify that Files is being used in name lookups by something like

nsquery hosts

[Steven E. Protter · Accepted solution]

I ran into this same issue. The problem was due to the version of DNS on Microsoft based DNS servers. It simply wasn't compatible with standards and was very slow to respond to Unix system requests.

I think going files first in nsswitch is a stopgap measure. It requires you to maintain your /etc/hosts database and you can very quickly get out of synch with changes in your environment because there is no means to get changes to you other than the good graces of the DNS administrator letting you know.

I would suggest the following items:

Try dns first in nsswitch.conf

Contact the DNS admins. If they use microsoft, make sure they are up to date on fixes and downloads

Make sure your system is updated to the latest BIND/DNS 9.2.x
http://software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=BIND9.2

You can set one of your hp-ux servers as a secondary or slave DNS server and have your Unix boxes take DNS information off of a standards based Unix BIND/host system.

SEP

[Ralph Grothe]

If it's really a DOMAIN inconsistent nameserver implementation that is serving your requests maybe one could set up a caching only nameserver on your Unix box,
like one does if one connects a Linux box via an ISP.

Also the nslookup program itself seems to be implement differently on varoius Unix flavours.
I can recall that I had to use the getent utility on a Solaris box to check my nsswitch.conf as nslookup didn't care at all for a files entry in there but went to contact the DNS server right away.

Besides, I'd suggest to move to the dig utility for DNS troubleshooting, a tool Linux distros adopted to replace nslookup.

[Anders Gullberg]

You got a point Steve!
We used v. 4.9.7 of bind, pretty old i guess.
On the windows side idont want to guess....