1. Introduction
Hosts files are one of the most basic ways to map names to addresses. In Linux, /etc/hosts is often the main file that holds such mappings. Still, the hosts file depends on the /etc/nsswitch.conf file settings. In any case, a hosts file enables users to assign a string to a numeric address, thus usually creating easier-to-remember commands and names. To ensure that our string-to-address maps are correct, we might need to perform checks.
In this tutorial, we explore ways to verify the settings within the /etc/hosts file and host mappings in general. First, we talk about the syntax of /etc/hosts and how to visually confirm it contains correct entries. Next, we explore tools that may seem helpful but actually aren’t. After that, we go over different utilities that perform host resolution based on the hosts file. Finally, we see how to control how the system resolves names.
To have a way of verifying the results, let’s use ping to confirm a given name isn’t resolvable and create a sample entry for it in our /etc/hosts file:
$ ping xost
ping: xost: Name or service not known
$ cat /etc/hosts
10.66.60.1 xost
We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. It should work in most POSIX-compliant environments unless otherwise specified.
2. /etc/hosts Syntax
The /etc/hosts file has a very basic syntax:
$ cat /etc/hosts
IPAddress Hostname Alias1 ... AliasN
###.###.###.### CANONICAL_NAME ALT_NAME_1 ... ALT_NAME_N
Usually, the Hostname column contains the canonical name for the value in IPAddress, while the next columns specify alternative names.
For better or worse, the syntax of a hosts file is very loose. In fact, we can add just about any data in /etc/hosts without problems. However, the results might be unexpected.
Finally, we might need to restart the networking services for any changes to take effect.
3. (Not) Using DNS Tools
When talking about network names in the context of computers, the Domain Name System (DNS) inevitably becomes part of the conversation. Because of this, we look at several DNS tools to check host names.
As one of the most common tools to check DNS records, we can employ dig with the sample name from our /etc/hosts file:
$ dig xost
[...]
;; QUESTION SECTION:
;xost. IN A
;; AUTHORITY SECTION:
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com.[...]
As we can see, the output of dig with our hostname yields no answer for our host.
Furthermore, the situation is the same with both nslookup and host:
$ nslookup xost
[...]
** server can't find xost: NXDOMAIN
$ host xost
Host xost not found: 3(NXDOMAIN)
The reason behind these results is the fact that DNS tools query an external DNS server directly, thus bypassing any hosts file.
So, let’s look at tools that respect /etc/hosts.
4. Using getent
The universal getent command can retrieve entries from different name databases as configured in the nsswitch.conf file:
$ getent ahosts xost
10.66.60.1 STREAM xost
10.66.60.1 DGRAM
10.66.60.1 RAW
Here, we use the ahosts switch as it ensures we perform the query against the current hosts database.
In this case, we can see the IP address we mapped for xost. Thus, by default, getent queries the information from /etc/hosts, thereby enabling us to test the entries without external requests.
Still, as we’ll find out below, this behavior can change based on the settings of the system.
5. Using gethostip
Another tool that handles the resolution of hostnames is gethostip, part of the syslinux-utils package.
Since distributions like Debian don’t include gethostip by default, we can install it via apt:
$ apt-get install syslinux-utils
Now, let’s see how gethostip behaves with our /etc/hosts entry:
$ gethostip -d xost
10.66.60.1
Here, the -d flag strips everything in the output except the IP address format in decimal format. Thus, we see the expected numeric mapping of xost.
Let’s check the behavior without any flags:
$ gethostip xost
xost 10.66.60.1 0A423C01
Notably, the default output includes the hostname as well as the IP address in hexadecimal format.
Again, although it uses the hosts file by default, how gethostip resolves depends on a configuration file.
6. Using Tools Like ping
The ubiquitous ping tool includes a name resolution mechanism that respects the contents of /etc/hosts:
$ ping xost
PING xost (10.66.60.1) 56(84) bytes of data.
[...]
Although it times out due to the non-reachable target, the ping shows us the IP address we added in the host entry in parentheses right after its name.
Yet, since ping can use gethostbyname(), gethostbyname2(), and similar, we can change its behavior via a system configuration file.
7. Resolution Precedence in /etc/nsswitch.conf
While there are multiple tools that internally resolve names to addresses, many rely on an internal operating system (OS) mechanism like gethostbyname().
To control where and how the system looks for the numeric equivalent of a name, /etc/nsswitch.conf provides a hosts entry:
$ cat /etc/nsswitch.conf
[...]
hosts: files mdns4_minimal [NOTFOUND=return] dns
[...]
This is often the default value of hosts, resulting in an initial files lookup. Thus, /etc/hosts is checked first. After that, we continue with DNS lookups.
If we change this precedence or remove the files entry altogether, we exclude /etc/hosts from the chain:
$ cat /etc/nsswitch.conf
[...]
hosts: mdns4_minimal [NOTFOUND=return] dns
[...]
This way, commands that employ the underlying kernel mechanism for name resolution will now skip over any file checks.
8. Summary
In this article, we talked about ways to test the configuration of /etc/hosts as the default hosts file of most Linux distributions.
In conclusion, when checking the host mapping changes, it’s critical to know the underlying mechanism that’s employed, so we can ensure there is a reference to our entries.