How is priority determined in /etc/hosts?

Question

For reasons too specific to detail here... I have tried to add two entries for a domain to the /etc/hosts file on a CentOS-7 server. In order for one piece of software to run happily, there needs to be an entry like:

192.168.1.z  otherserver

however, I actually want that domain to resolve to a different IP:

10.w.x.y     otherserver

My understanding (backed up by similar questions eg Assign multiple IPs to 1 Entry in hosts file) is that the first matching entry will be used.

So this file:

192.168.1.z  otherserver
10.w.x.y     otherserver

should lead to the domain resolving as 192.168.1.z; whereas this file:

10.w.x.y     otherserver
192.168.1.z  otherserver

should lead to it resolving as 10.w.x.y.

However, no matter what ordering I use (and however many duplicate entries I add) the domain always resolves as 192.168.1.z unless I remove that entry completely.

So is there any way to include both lines but ensure that 10.w.x.y takes precedence?

Solution

Top to bottom. That's usually it.

You may want to also examine your /etc/nsswitch.conf

Other services may use a different method of DNS lookup. What application is this?

Also, check for caching daemons. Is nscd running?

Comments

[Thomas]

Normally the first match wins in /etc/hosts. Any caching mechanisms? How do test your resolution? ping? In a browser? Besides that, you should use FQDNs for different subnet addresses.

[Chris Throup]

Re FQDNs... the real issue which gave rise to this is the failure of a single network interface on a cloud server. For the application involved (irrelevant to this question) I needed to use the same FQDN, but I wanted it to route via the IP on the other subnet. Using this approach with /etc/hosts was just a quick hack which didn't work as expected... and I'm curious to know why.

[ewwhite]

We don't know what your DNS setup is or have examples of what you're pinging. More detail... otherwise, we can't help you. And why are you obfuscating internal IP addresses? The application is NOT irrelevant, as some processes may do a DNS lookup at startup and never reference your host file again. It all depends.

[Chris Throup]

The application which led to this scenario is irrelevant. A specific application which is picking up 192.168.1.z (pretend the z is a 1 if it helps) is ping executed from a bash terminal over an SSH connection to a CentOS cloud server. Hosted on a cloud platform where the 10.* IPs are private from the internet, but not from other client's servers.

[Chris Throup]

Top to bottom is what I expected... but doesn't seem to be the case for this server. Nothing obvious to me in /etc/nsswitch.conf: hosts: files dns myhostname Ping and puppet are two applications which are showing this behaviour. No caching daemons in effect. Adding the entry (anywhere in the file) to /etc/hosts takes effect pretty much instantly.