up vote 10 down vote favorite
5

In my linux machine, when I run hostname, it shows mongodb, but when I run host mongodb, it shows:

mongodb@mongodb:/var/hadoop/hadoop-1.2.1/bin$ host mongodb
Host mongodb not found: 2(SERVFAIL)

My /etc/hosts file:

192.168.10.10   mongodb
192.168.10.10   localhost
127.0.0.1       localhost
#127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

  • My first question is: Since /etc/hosts is mapping from IP to hostname, why this machine cannot resolve the hostname mongodb to IP 192.168.10.10? Instead, when I run host localhost, it can be resolved and shows:

    localhost has address 127.0.0.1

  • My another question: According to the /etc/hosts file, the hostname localhost should have been resolved to 192.168.10.10 instead of loopback IP address 127.0.0.1. Anybody can explain this to me?

share|improve this question
up vote 23 down vote

The host (and nslookup) utilities explicitly query DNS servers, and do not consult the /etc/hosts file in a default system configuration. If you were to traceroute or ping that address, you would see it correctly resolve.

You do not want to change localhost to map to anything other than 127.0.0.1, this can have strange and subtle effects on many things. I think that /etc/hosts is parsed in the order in which it is written, and since you have:

192.168.10.10   localhost
127.0.0.1       localhost

..the second entry may be overriding the first.

share|improve this answer
  • 4
    /etc/hosts does not have any effect on DNS resolution when querying DNS servers directly, which is what host does. However, many system tools and utilities use the localhost definition, expecting it to be a loopback address, and use system name resolution (which looks at /etc/hosts before querying DNS) to resolve names rather than strictly going to DNS, which may not always be present. – DopeGhoti Jan 14 '14 at 17:16
  • 1
    I can also share experience with problems in the /etc/hosts file regarding localhost. In the past we had used some software that would insert a 127.0.0.2 localhost in the hosts file and with that being the last localhost entry causing it to be the one in effect caused all kinds of software and license problems. So my recommendation is to have 127.0.0.1 localhost as the first entry in your /etc/hosts file and make sure there is no other localhost entry in that file. And I would also verify any ipv6 stuff as well. – ron Aug 26 '16 at 18:32
  • 3
    To be somewhat pedantic, both do a ns lookup which might be a dns lookup if that is how you have configured the host lookup in nsswitch.conf. – symcbean Aug 26 '16 at 20:48
  • 1
    @symcbean - what you say is correct. I wouldn't call that pedantic. – DarkHeart Aug 27 '16 at 3:21
  • 2
    A notable non-obvious exception to this is if your /etc/resolv.conf points to a DNS server running directly on your device (like a caching dnsmasq) and said server is consulting your local /etc/hosts before querying external servers. Then, indirectly, commands like host will be effected by your /etc/hosts - this is an uncommon setup, but one I have seen devices ship with, and experience of someone using such a system can seem to conflict with this answer if someone is unaware of this peculiar setup. – mtraceur Nov 18 '17 at 0:07
up vote 8 down vote

In addition to DopeGhoti's answer, to test your resolving, inlcuding the /etc/hosts precedence, you can use the getent hosts <some_hostname> command.

share|improve this answer
up vote -3 down vote

I got similar issues with a /etc/hosts containing multiple spaces between IP and hostname, instead using a TAB. After changing to TAB the hostname could be resolved by ping.

127.0.0.1        test.local
         ^^^^^^^^ → Should be a TAB not multiple spaces.

see also on https://superuser.com/a/938366/467479

share|improve this answer
  • 4
    This surprises me. The manpage for hosts says: Fields of the entry are separated by any number of blanks and/or tab characters. Perhaps in your case there was some extraneous non-printable character between the IP and the hostname? – dr01 Jul 9 '15 at 12:54
  • There weren't definitively no non-printable characters. I checked this before I posted this here ;) – Thomas Lauria Sep 29 '15 at 8:46
  • I don't have tab characters, I run SLES 11.x, and after clean installation from dvd my /etc/hosts file has 127.0.0.1 followed by 7 spaces followed by localhost. So i would be a little hesitant to pin the problem specifically on multiple space characters and concluding using the tab character as the solution. – ron Aug 26 '16 at 18:28
  • forgot to mention the tab versus space may also happen within a specific version or distribution of linux, which may be a bug? and if this were the case you should be able to make various ip address / hostname entries with either a tab or a space, then do a ping on them to see if it gets resolved... just don't do it with localhost – ron Aug 26 '16 at 18:38
  • unfortunately I don't remember on which machine (and therefore distro) I experienced the problem... - I think it was on Ubuntu 15.05 from virtualboximages.com/… I am going to evaluate that. – Thomas Lauria Aug 30 '16 at 12:08

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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