Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to connect from a 10.04 system to a 12.04 system via SSH. Strangely enough the rules in resolv.conf seem to take effect only selectively, which leaves me puzzled. Observe:

[2] user@mach:~$ ssh pangolin
ssh: Could not resolve hostname pangolin: Name or service not known
[2] user@mach:~$ host pangolin
pangolin.subdomain.domain.tld has address

subdomain.domain.tld is on the search line in /etc/resolv.conf and using host the name is properly searched given those rules. However, with the SSH client ssh I receive the error reproduced above. How can this be? I was always of the impression that the name resolution rules in resolv.conf apply system-global.

Note: /etc/hosts doesn't declare the name pangolin at all. The package openssh-server is configured on the target machine. The question is purely about why name resolution isn't consistent between those two programs.

Another note: the command works fine when I enter the fully-qualified domain name, i.e. pangolin.subdomain.domain.tld.

Meanwhile I rebooted the client machine (10.04) and the problem still exists. A DNS caching daemon isn't installed, so I reckon that shouldn't have been a problem anyway.

The information asked for in the comment:

$ grep host /etc/nsswitch.conf
hosts:          files dns

/etc/resolv.conf, I transformed the domain names consistently:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
search domain2 domain2.ccTLD

... and the full /etc/nsswitch.conf:

$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

... and /etc/network/interfaces, which is the source for resolv.conf in 12.04:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        dns-search domain2. domain2.ccTLD.

Note: the transformation of the domain names was done with sed, so it's consistent between the various reproduced files.

There is no ~/.ssh/config, but here's the global one (/etc/ssh/ssh_config), shrunk for the sake of brevity:

$ grep -v '^#' /etc/ssh/ssh_config |grep -v '^[[:space:]]*$'
Host *
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no

$ mtr pangolin
Name or service not known: Success
share|improve this question
Could you post your /etc/resolv.conf and the output of this command grep host /etc/nsswitch.conf ? – Awi Jun 12 '12 at 1:10
@Awi: added it, plus a bit more. – 0xC0000022L Jun 12 '12 at 17:29
Two questions 1) Does it work as intended if you use the fqdn? 2) Can you post the contents of ~/.ssh/config and /etc/ssh/ssh_config to see if there is any weirdness. – Patrick Regan Jun 12 '12 at 18:01
@PatrickRegan: I'll edit the requested stuff into the question. Yes, it works with the fqdn :) ... (will also adjust the question in that respect) – 0xC0000022L Jun 12 '12 at 21:01
@STATUS_ACCESS_DENIED: Do you see anything weird with mtr pangolin ? – pl1nk Jun 12 '12 at 23:11
up vote 5 down vote accepted

Whereas ssh and other programs such as ping use the glibc resolver to look up the host name ('pangolin' in this case), host looks the name up in DNS directly, bypassing the glibc resolver. That's the difference.

However, given that the glibc resolver is, on your machine, configured to try dns after files, I can't explain why the resolver fails where host succeeds.

I have seen this behavior reported before when dnsmasq was used as a local forwarding nameserver ( but you aren't using such a local nameserver; but perhaps the problem there and here wasn't in dnsmasq but in the glibc resolver.

share|improve this answer
Profound and succinct answer. Way to go! Thanks. – 0xC0000022L Nov 1 '12 at 20:46

Your ssh may try to resolve IP6 and time out doing this. If you are not using IP6 try disabling IP6 in /etc/ssh/ssh_config by changing AddressFamily from any to inet.

share|improve this answer

I've come across this a couple of times, and it always throws me until I remember the six domain restriction on the search list in resolv.conf.

share|improve this answer
1. This is a very good point. The question text includes a listing of the resolv.conf file (although it appears to have been edited to anonymize the information). The file's search line contains more than six domain names. The glibc resolver only looks at the first six domains or 256 characters, whichever is less. I speculate that the host utility has no such restriction, and that host succeeds in resolving the name with the seventh or later domain name extention. – jdthood Feb 20 '15 at 20:29
Note also that there should not be both a dns-search line and a dns-domain line in a single stanza in /etc/network/interfaces. The dns-domain option is actually deprecated; all search domain names should given be on the dns-search line. – jdthood Feb 20 '15 at 20:33

i got this error by putting a domain entry line before the 2 nameserver lines by accident. nslookup worked. wget worked. ssh, scp, rsync failed.

moving domain to below nameservers and saving resolv.conf fixed. nothing else was necessary for me.

share|improve this answer

I was facing trouble accessing my sftp server. The ftp user was not able to loggin to sftp from another server. (Solaris - Openssh). I commented the "dns" entry in the nsswitch.conf and the issue resolved.

Thanks Arun Janardhanan ( IBS Software Services )

share|improve this answer

I know that this is an ancient question, but I'll add in what worked for me.

I had the same issue and found that in my nsswitch.conf, there was mdns in addition to files and dns. Removing mdns4 resolved this issue for me.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.