Understanding Linux hostname resolution

On a network, it's much more convenient to look up other resources by name, rather than remembering the IP address of every resource we connect to. By default, looking up hosts by name may not function without a little configuration. For example, you can try the ping command against the name of one of your Linux machines, and you may or may not get a response. This is because a DNS entry for the resource you're connecting to might not exist. If it doesn't, you'll see an error similar to the following:

ping: unknown host potato

However, if you ping the device by its IP, it would more than likely respond:

64 bytes from 10.10.96.10: icmp_seq=2 ttl=64 time=0.356 ms

The reason for this is in order for a network host to be able to contact another, it needs to know its IP address. If you type in a name instead of an IP address, the machine will attempt hostname resolution, and if there is a valid entry in Domain Name System (DNS) for the machine you're attempting to contact, you'll be able to receive a reply. In Microsoft networks with Windows-based Dynamic Host Configuration Protocol (DHCP) and DNS servers, it's very typical for the server to register a dynamic DNS entry whenever it assigns an IP address to a host. Linux-based DHCP and DNS servers are capable of dynamic DNS as well, but it's not configured by default and it's rarely enabled by the administrator. In an all Linux network or any network that doesn't assign DNS dynamically, this ping would most likely fail. We discuss DNS in more detail in chapter Chapter 6, Configuring Network Services.

In most cases, DNS is not the first place that a Linux host will look in order to resolve hostnames. There is also a file saved locally on the system (/etc/hosts) that your machine will check first. If an entry for the host you're contacting isn't included there, your machine will then contact its configured primary DNS server in order to find an IP address for the name that you entered. Here's an example of a host file:

127.0.0.1 localhost
127.0.1.1 trinity-debian

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

In the hosts file presented, we can see an entry for localhost and an entry for trinity-debian. Both of these entries, which begin with a 127.0.x.x IP address, represent the machine itself. To test this, try pinging localhost as well as the name of your machine (in this case, trinity-debian). Either way, you'll get a reply. This is because the machine is aware of its hostname, and localhost uses the loopback adapter to reach itself. If you desired to do so, you could create additional name to IP address matches within this file. For example, if you had a computer named potato at IP address 10.10.96.10, you could add it to the end of the hosts file as follows:

10.10.96.10 potato

From now on, you'd be able to reach IP address 10.10.96.10 by typing in potato. You could ping it, or even enter it into the address bar of your browser (providing the machine was serving web content). In fact, the host entry doesn't even need to be a local resource in your network. You could even enter an IP address for an external website, and reach it by a different name. However, this only works in theory—a well-designed website may not operate under such circumstances.

While /etc/hosts is checked first, your Linux installation includes a file, /etc/nsswitch.conf that it uses to make the ultimate determination on the order in which host resolution occurs. The line in question begins with hosts, and you can easily check the host resolution order on your machine with the following command:

cat /etc/nsswitch.conf |grep hosts

You'll get the following output:

hosts: files mdns4_minimal [NOTFOUND=return] dns

Here, we can see the system is set up to check files first, which represents local files, which includes /etc/hosts. If the search is for a local domain and it is not found, the NOTFOUND=return entry causes the remainder of the search to abort. If you're searching for anything else, the next resource that will be used is DNS, as shown with dns being the last entry. Unless you changed this file, chances are that your distribution will also be set up to look within local hosts files first, and then DNS if the resource is not found locally.