Questions about name resolving using /etc/hosts

I am running OpenSuSE Leap 42.3 on a machine with 2 NICs. I am also running a Bind DNS server on the same system. I did an experiment in order to assign a unique hostname to each of the NIC interface cards by simply editing my /etc/hosts file as shown below:

bigbang:/etc # cat /etc/hosts

127.0.0.1    localhost
# added for each nic
192.168.10.100  bigbangInternal.mydomainname.com bigbangInternal
10.10.10.100    bigbangExternal.mydomainname.com bigbangExternal

::1             localhost ipv6-localhost ipv6-loopback
fe00::0         ipv6-localnet
ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts


My host.conf file is configured to look at the hosts file first when resolving names:

bigbang:/etc # cat /etc/host.conf

## file comments deleted for brevity...

order hosts, bind
multi on

My nsswitch.conf file is also configured to look at the hosts file first when resolving names:

bigbang:/etc # cat /etc/nsswitch.conf

## file comments deleted for brevity...

passwd: compat
group:  compat

hosts:          files mdns_minimal [NOTFOUND=return] dns
networks:       files dns

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files nis
publickey:      files

bootparams:     files
automount:      files nis
aliases:        files
 


After editing the /etc/hosts file I flushed the name service cache:

bigbang:/etc # systemctl restart nscd.service

and when I test things out I get the following “surprising” results which appear at first glance to show that the name resolving order specified in nsswitch.conf is not being honored. But something else even deeper is going on as well that really has me baffled:

bigbang:/etc # ping bigbangInternal
ping: unknown host bigbangInternal

??? didn’t expect that!

bigbang:/etc # getent hosts
127.0.0.1       localhost
192.168.10.100  bigbangInternal.mydomainname.com bigbangInternal
10.10.10.100    bigbangExternal.mydomainname.com bigbangExternal

that looks good…

bigbang:/etc # getent hosts localhost
::1             localhost

??? I am a bit surprised by this as I did not enable IPv6 addresses in YaST

bigbang:/etc # getent hosts bigbangInternal
bigbang:/etc # getent hosts bigbangInternal.mydomainname.com


??? no response! why not?

bigbang:/etc # getent hosts 10.10.10.100
10.10.10.100    mydomainname.com

??? huh? why did I get my dns domain name?

bigbang:/etc # getent hosts 192.168.10.100

??? no response!

My guess is that these attempts to resolve these names and ip addresses is being done by my bind dns server and not by looking things up in the /etc/hosts file. But I don’t understand why given that I am specifying that the order of lookup is to be done first via the /etc/hosts file and then by the bind dns server if the lookup in the hosts file fails. What am I missing and/or not understanding?

Thanks in advance for any guidance/clues as to why I am seeing these results.

Marc…

I found the cause of why I am seeing these anomalies but it is
indicative of another problem (bug?)Â Because I am doing some
experimentation and running OpenSuSE in a couple of different
configurations I had changed /etc/hosts so that it was a link to another
file instead of just a straightforward file in /etc. My guess is that
the libraries, which are designed to resolve host names and IP
addresses, using the /etc/hosts file are not capable of following links?
Once I removed the link and replaced it with the actual file things
worked pretty much as expected (except for the lookup of localhost which
is still returning an IPv6 address instead of an IPv4 address as I was
expecting)Â

So is this a bug? If not shouldn’t there at least be a warning/error
message that is helpful to unsuspecting users such as myself? This was
really hard to track down!

I’ve never seen someone use a link, but if the link is done correctly I would think it should work.
Keep in mind though that the /etc/hosts file is intended <only> for <local> name resolution so you shouldn’t linking to a remote location or sharing the file with other machines.

Aside from that,
You created two entries assigning your hostname to two interfaces which doesn’t make sense.
You should assign to only one interface so that applications running on your machine will map to the specified network interface consistently.
Again, you have to keep in mind this is only for <local> name resolution so what you’re configuring is relevant only to applications installed and running on your machine… and nowhere else.

TSU

Thanks TSU for taking the time to reply!

I would say try it and see if creating /etc/hosts as a link to another file works for you, and I would be curious to know what your mileage was… I found that creating a soft link to another file, same system but different partition, produced these failures.

Yep, I am fully cognizant of that!

It does if you are setting up services that should only run on one or the other interfaces, or like me setting up a mail server to run in split brain mode, i.e.handle internet traffic one way and intranet traffic another way. This will let me control which interface to interact with by name and not by IP address (which some brain dead configuration setups don’t support…)

And again, we are on the same page, the only applications that will use these interface names are services running on the same machine with the two NICs! lol! I run a BIND DNS server as well (again split-brained), on this system and all other applications and remote systems will use it for their own name resolution purposes.

Split brain should have no effect on whether to assign the same hostname to multiple network interfaces (It’s a poor idea).

Any and all network services should be assigned to a single network interface, no matter whether it’s your LAN network or for outside access.
When someone from outside the supported network needs access to that network service, you then configure a forwarding rule to provide that access.

You can still have split-brain, but instead of what you’ve set up you can have various hostnames mapping to the same IP address, and the service is bound to that <one> IP address on that one interface.

Doing it the way I describe greatly simplifies your security configurations.

This also partly depends on whether the particular network service uses name resolution…
Mail servers might support multiple IP addresses so could possibly be configured how you described, although against my recommendation.
Websites can be very name sensitive so has to be configured as I described.
Most other network services I’m thinking of at the moment are not name sensitive, are bound to to IP addresses.
3rd party apps often use name resolution which require what I described.

TSU