Entries in my /etc/hosts file on a RedHat AS 3.0 installation are not being resolved when I use nslookup. (Also when I use "dig" or "host" utilities.)

The entries DO get resolved when I use ping though.

Does anyone have a clue as to why this should be?

I've spent the morning looking through the web and the forums here but can't see this problem. The closest I saw was someone who had the opposite problem (ping didn't resolve but nslookup did). The details there didn't help. The info about /etc/host.info and libnss* was new to me but have both been checked.

Already checked based on my reading:
/etc/hosts - Yes it has the entries for which I'm looking.
/etc/resolv.conf - Yes it has my DNS servers correctly defined. (DNS queries are resolving correctly.)
/etc/nsswitch.conf - Yes it has "files" BEFORE "dns" for the "hosts:" line.
/etc/host.conf - Yes it has "hosts" before "bind" for the "order" line.
/lib/libnss_files.so.1 & /lib/libnss_files.so.2 do exist.
All the above files are world readable and the libnss* ones are world executable.

I know that nslookup is deprecated but as noted above I can't resolve with either the host command or the dig command.

Using the above commands I successfully resolve entries from my DNS servers. The problem appears to be that it is ignoring the /etc/hosts entries only.

This started out as a search for how to force reverse lookup to use the domain name specified for the host itself from its own /etc/hosts file. This was because it appears it was getting the reverse lookup from DNS instead. However on testing by adding a bogus remote host I found even a regular lookup doesn't seem to read /etc/hosts. Since ping works I'm assuming gethostbyname is working fine.

On checking my Debian Linux workstation I found I'm having the same problem.

On testing my HP-UX servers using exactly the same /etc/hosts entries there are no problems.

Since I'm relatively new to Linux administration I suspect it is some simple configuration item I'm missing. However everything read today suggests that the things I've mentioned as having checked above are the only things necessary to have this work.

My guess is that nslookup and dig and so on are made to query dns servers... and so will use the dns servers that you have set up at /etc/resolv.conf.... or the server you tell them to use... and so, they won't take a look at /etc/hosts.

Your guess doesn't seem likely. It certainly isn't true for Unix so I wouldn't expect it to be for Linux. From my (albeit somewhat limited) Linux experience most Linux utilitilies have enhanced functionality over their Unix counterparts.

Well... I'm not gonnay play the linux guru... cause I'm not.
However, I do wanna say that I just tried and the same happens to me. nslookup is not responding to the host names I have at /etc/hosts:
Any explanation?

Well... I'm not gonnay play the linux guru... cause I'm not.
However, I do wanna say that I just tried and the same happens to me. nslookup is not responding to the host names I have at /etc/hosts:

And it never will. As the name implies - nslookup and dig query name servers ONLY.

Although I have never looked at the source code - commands like ping are "probably" compiled to use functions like "gethostbyname", which would honer the order directive. i.e. hosts, bind.

Further reading:

man resolver
man gethostbyname

See? I told you! :-P

Well - I can see that it does NOT resolve however IHMO this is a flaw (read bug) in Linux.

As to what the "name implies" I'll say it implies only "name server" NOT "Dynamic Name Server". DESPITE this nslookup in all Unix flavors I've worked on (AT&T, NCR, SCO, Solaris, HP-UX, AIX) has always resolved from /etc/hosts so long as "files" was specified in the appropriate entry in /etc/nsswitch.conf. Note that NIS is also a "name server". The names of "dig" and "host" don't imply anything though I'll admit the man pages for all in Linux mention only DNS.

Perhaps the reason nslookup is being deprecated in favor of dig and host is due to the confusion caused by this basic funtionality difference between Unix and Linux. Just because people have learned to live with this inadequacy in Linux doesn't mean its the way it should be. Common troubleshooting for insuring one is resolving correctly in Unix has always been to use nslookup to see what it returned then check the /etc/hosts, /etc/resolv.conf and /etc/nsswich.conf files.

As an FYI: I DID read the man page for gethostbyaddr before posting. It clearly states it parses /etc/hosts. Telling me to read it was pointless since you say nslookup doesn't use it.

Anyway enough of that - lets change the question to:

Is there a pebuilt utility that allows one to resolve names or IP addresses whether they come from /etc/hosts, DNS or NIS in Linux?

1 members found this post helpful.

"getent ahosts myhost.example.com"

2 members found this post helpful.

Wow - 7 years later...

Thanks anyway.

If you want to help you might want to help folks with more current questions:
Zero Reply Threads

Anyway just to finish out this thread:
It turned out that HP-UX had a specific version of nslookup written to check /etc/hosts AND name servers whereas most other commercial UNIX variants and Linux do NOT.

Also nslookup is deprecated by ISC the makers of BIND. You should use the "host" command where available instead. You should use "dig" for troubleshooting DNS lookups. Neither of those will interrogate /etc/hosts though.

Omg! waiting 7 years so bad...

As an FYI I have NOT been waiting 7 years.

My point was that posting responses to a 7 year old thread when there are many "zero reply" threads for current questions seems to be ignoring the main point in this site.

I changed the status of this thread to SOLVED after the recent post and note that marking threads SOLVED wasn't an option 7 years ago.

already

My reply was just for reference; I was having the same interogation than you 7 years ago and google pointed me to your post, which was helpful but incomplete. Now people will get the response from it.

Cheers.

1 members found this post helpful.

Two years and a half later, I'd like to thank you, Fravadona, for answering to this thread (which means you had to subscribe and all, just to provide an answer for you fellow googlers).

Hi,

This is 10 years later and still stumbling upon this thread. Thanks to Fravadona for her excellent answer, regards,

Miguel