Strange resolv.conf behaviour

[Mark McDonald_2]

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

[Torsten.]

What is your nsswitch.conf telling you?

DNS first, then hosts?

[Mark McDonald_2]

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.

[TTr]

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.

[Bill Hassell · Accepted solution]

> 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)

[Mark McDonald_2]

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

[Bob_Vance]

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