topic Re: Strange resolv.conf behaviour in Operating System - Linux

Strange resolv.conf behaviour

Mark McDonald_2 — Mon, 11 Aug 2008 12:43:18 GMT

Hi

I have/had a machine where ssh and traceroute were taking about 30 seconds to respond on the shortname, but responding immediately on the fully qualified name. telnet and ftp worked straight off. nslookup worked fine on all hostnames (long and short) and on ip addresses.

I have tracked this down to an old nameserver entry in the resolv.conf. Now I thought that it would pick the top name server and lookup on that first, then move to the next etc.

My resolv.conf had:
domain domain.com
search domain.com other.com etc.com
nameserver new_IP
nameserver old_IP

I have removed the last (old_IP) entry and ssh responds immediately. I guess the lookup was timing out looking for the old nameserver which has been decomissioned. Should it even look for it? I dont understand why it even looked at the 2nd nameserver?

All other protocols must have only used the 1st nameserver. Is this some sort of security built in to ssh?

Anyone care to comment?

Thanks
Mark

Re: Strange resolv.conf behaviour

Torsten. — Mon, 11 Aug 2008 12:46:10 GMT

What is your nsswitch.conf telling you?

DNS first, then hosts?

Re: Strange resolv.conf behaviour

Mark McDonald_2 — Mon, 11 Aug 2008 12:49:54 GMT

There is no nsswitch.conf

I did create one at one point and add some entries to /etc/hosts, and all started working fine, so this led me to think it was a DNS issue so I removed it again to continue my investigation.

Like I said it is all working fine now the dead nameserver entry has been removed. I was just wondering why the 2nd entry was causing this to happen.

Re: Strange resolv.conf behaviour

TTr — Thu, 14 Aug 2008 20:19:52 GMT

I came across this text from patch PHNE_35730

The netstat command seems to hang while resolving the network or host addresses to names, if the nameserver directive in the /etc/resolv.conf file points to an invalid DNS server

This certainly fits your problem but the patch is for 11.00 and don't know if it matches your case. Patch PHNE_27063 is the equivalent patch for 11.11 with the same text in it.

Re: Strange resolv.conf behaviour

Bill Hassell — Thu, 14 Aug 2008 22:54:02 GMT

> no nsswitch.conf

Not a good idea at all. What this means is your entire machine's network activity is dependent on another system (DNS). And as you have seen, a dead or unreachable DNS server will cause a 30 second delay to try the next one. Because of this, I always create the nsswitch.conf file and specify files, then DNS, like this:

passwd: files
group: files
hosts: files [NOTFOUND=continue UNAVAIL=continue] dns
ipnodes: files [NOTFOUND=return] dns
networks: files
protocols: files
rpc: files
publickey: files
netgroup: files
automount: files
aliases: files
services: files

Then you put production system hostnames into /etc/hosts where name resolution in infinitely faster. This will also improve performance in commercial backup products. There is no protocol involved here, it is all part of the resolver library (see: man 4 resolver) and how each network service translates hostnames into IP addresses.

A useful tool (in addition to nslookup) is nsquery (man nsquery)

Re: Strange resolv.conf behaviour

Mark McDonald_2 — Tue, 19 Aug 2008 09:29:30 GMT

Thanks Bill, I am a contractor and have been handed the box in this state so I will be adding an nsswitch.conf

Re: Strange resolv.conf behaviour

Bob_Vance — Thu, 05 Feb 2009 21:56:24 GMT

I had a very similar issue after moving to HPUX 11.23 - 30 seconds delay on shortnames.
This ocurred with both version 4.7 and the latest version 5.10 of SSH.

I did network tracing and concluded that SSH and REMSH do not even use nsswitch. They appear to have a built-in resolver that is hard-coded to use this order:
. dns
. files

Please see my post and fix for SSH at:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1233870592210+28353475&threadId=1311413

tks
bv