Slow response from local connections using

[vdf]

Hi all,

I have a problem in 1 server. If I try a ssh, telnet,ftp,etc to itseft i have to wait for 10-15seg to see the answer "login: "

It only happens with the short name "webap7p" if i try with the webap7p.prod.domain.es it works fine, also with the ip address


I have checked /etc/hosts, /etc/resolv.conf, /etc/nsswitch.conf... and they seem to be ok.

I did some tests moving /etc/resolv.conf and fix the problem but the server only can resolv the /etc/hosts machines...

If i configure /etc/nsswitch.conf with only files the problem continues...I have to delete or move /etc/resolv.conf to get a fast connection to itsetf using short names.

Why does it happend?

Thanks!

[Horia Chirculescu]

Hello,

Try to add the line

192.168.1.1 webap7p

to /etc/hosts. Change 192.168.1.1 to whatever you need.

Also, in your /etc/nsswitch.conf you should have:

hosts: files dns

Order is important.

Best regards,
Horia.

[Horia Chirculescu]

You can also use the directive (in sshd_config add the following line):

UseDNS no

from the man page:

UseDNS Specifies whether sshd(8) should look up the remote host name and
check that the resolved host name for the remote IP address maps
back to the very same IP address. The default is ``yes''.

Best regards,
Horia.

[vdf]

Hi,

This is the entry in the /etc/nsswitch.conf:

hosts: files [NOTFOUND=continue UNAVAIL=continue] dns [NOTFOUND=return UNAVAIL=continue TRYAGAIN=return]

and hosts file:

127.0.0.1 localhost loopback
10.40.4.144 webap7p webap7p.prod.airtel.es EJBnetwork
10.40.4.145 webap8p webap8p.prod.airtel.es
10.40.4.146 webdocssi webdocssi.prod.airtel.es
192.168.0.1 webap7phb
192.168.0.2 webap8phb


I trace the telnet command with tusc and "telnet 10.40.4.144" doesn't check /etc/resolv.conf but "telnet webap7p" does...

[Horia Chirculescu]

And telnet 10.40.4.144 does not exhibit slow response?

Horia

[Horia Chirculescu]

In /etc/resolv.conf do you have the line:

domain prod.airtel.es

Horia.

[vdf]

telnet 10.40.4.144 works very fast...

Here is my resolv.conf:

search prod.airtel.es des.airtel.es red.airtel.es ing.airtel.es vf-es.internal.vodafone.com es.sedc.internal.vodafone.com
nameserver 10.40.3.143
nameserver 10.10.32.100
nameserver 10.10.37.250

[Horia Chirculescu]

Run nslookup and see how webap7p is resolved.

Horia.

[vdf]

It seems that only check the /etc/hosts:

webap7p:/tmp># nslookup webap7p
Using /etc/hosts on: webap7p

looking up FILES
Name: webap7p
Address: 10.40.4.144
Aliases: webap7p.prod.airtel.es, EJBnetwork


But tusc show that it check /etc/resolv.conf too.

[TARUN SHARMA_1]

Try to add the line
192.168.1.1 webap7p
to /etc/hosts.

[TARUN SHARMA_1]

Try to add the below line on the box from where you are running telnet or ssh
192.168.1.1 webap7p
to /etc/hosts

[Horia Chirculescu]

Have you tried to insert the line

domain prod.airtel.es

at the beginning of resolv.conf?

[vdf]

Hi Tarun,
Why 192.168.1.1? webap7p only has the lan0 configured with 192.168.0.1 and is already configured in /etc/hosts as webap7phb

192.168.0.1 webap7phb

"telnet webap7phb" is also slow..and "telnet localhost" too

127.0.0.1 localhost loopback

But telnet 192.168.0.1 or 127.0.0.1 work fast.

[Steven Schweda]

> Run nslookup and see how webap7p is
> resolved.

If the problem lies with DNS, then I'd worry
more about the reverse look-up of your
_client_ system (on the server).

nslookup client_IP_address

[vdf]

webap7p:/># nslookup webap7p
Using /etc/hosts on: webap7p

looking up FILES
Name: webap7p
Address: 10.40.4.144
Aliases: webap7p.prod.airtel.es, EJBnetwork

My question is...why does it check resolv.conf if the name is in hosts file and nsswitch.conf if configured correctly to work only locally?

[Bill Hassell]

> My question is...why does it check resolv.conf if the name is in hosts file and nsswitch.conf if configured correctly to work only locally?

"work only locally" means that nsswitch.conf has this line (exactly):

hosts: files

I think you'll find nsquery more informative than nslookup. The important setting is in nsswitch.conf where the actions to lookup a hostname are defined. To looki in /etc/hosts first, then DNS, make sure the hosts: line reads:

hosts: files [NOTFOUND=continue UNAVAIL=continue] dns

Then run nsquery to see how the rules are followed:

nsquery hosts webap7p

[rick jones · Accepted solution]

When ssh, telnet, ftp, etc go to resolve the "short" name you give them - webap7p - the name resolution routines (the DNS ones anyway) will then start to "search" for the complete name. That will be controlled by either the "search" or "domain" lines in the /etc/resolv.conf file.

If you were to take a verbose tusc system call trace, you could probably see a series of names being tried in turn until it got one that resolved. Similarly if you were to install tcpdump and take a packet trace of traffic to/from port 53, you could probably see the sequence of names being searched.

The heuristic (as I recall it) is that if there are two or more "dots" in the name (such as with your webap7p.prod.domain.es) the resolver code will ass-u-me it is a Fully Qualified Domain Name (FQDN) and try that first before messing with its search entries.

Also, if there is a trailing dot - eg foo.bar.baz. the resolver code will also assume it is an FQDN and not step through its search paths at all.

If there is much latency between this system and your DNS servers, or if the search directive in /etc/resolv.conf call for searching external domains, it could quite possibly take a little while to go through the search.

This is all independent of whether or not the actual destination is local to the machine :)

[vdf]

Thanks for the answers!

The problem is solved. I changed the dns order in the resolv.conf and now the conections with the short name works perfectly. The problem seems to be in the first dns was setting in the resolv.conf...

Thanks,
Javi

[Horia Chirculescu]

Hello,
In this case you should ask the admin which is responsible with the

nameserver 10.40.3.143

to check the DNS setup (reverse lookup problem maybe?).

Best regards
Horia.

[vdf]

Maybe...or perhaps a network problem...I'm going to investigate that!

Thanks!

[vdf]

See comments above.