Linux – proper relationship between /etc/hosts and DNS A records for a Linux server

There are a number of different ways to achieve this. Obviously, you don't want to create A records for both the public and private IP addresses and publish those records for public consumption, because then users will try to access via the private IP. If multiple A records are listed for a single name, they will be used in a round robin resulting in users sometimes being unable to connect.

Here are a few solutions I've used:

My favorite solution is to create a DNS sub-zone for these servers, perhaps called "private.example.com". Then the servers in "example.com" that have private IP addresses I list in the "private.example.com" zone. Then configure your /etc/resolv.conf (probably via DHCP) so that when you are connected to the private network your DNS search path is "private.example.com example.com". Now, if you try to access "hostname", it will first try looking up "hostname.private.example.com." and then "hostname.example.com". So you any hosts in that domain that don't have private IPs you don't have to list in multiple places. You can also explicitly reference the public IP by saying "hostname.example.com" and similarly for the private IP. But if you just say "hostname" it will search for a match.

Note: If third-parties realize there is a "private.example.com" zone they may be able to query or "dig" it and see IP addressing. Revealing of this information may be of concern to you, depending on your exact requirements, but for my needs revealing some private IP addresses has never been a problem.

You can configure what BIND calls "views". Here's a link to another question that shows an example configuration of views. Basically, you configure Access Control Lists saying what zone file to use to answer the request based on what IP address is requesting it. So if you get a request from the private network, you could respond with the private IP. Views can be difficult to configure and maintain, however. There is also an issue of keeping duplicate copies of records in the different views, see my next suggestion for more details.

If your private network has a host you can run DHCP and DNS on which is separate from your public DNS server, you may want to set up DNS on this host as the default DNS server for machines in the private network, and then set up the DNS server to answer queries for these machines using the private IPs. However, if not all machines in the DNS zones you are interested in are going to have private IPs, this may lead to duplication of records where you now have to list IP addresses for servers in both DNS servers. Similar to Views above, but conceptually a little simpler to setup and test as you have completely separate DNS servers.

These days, a system may have multiple interfaces, each with multiple addresses, and each address may even have multiple DNS entries associated with it. So what does a "system hostname" even mean?

Many applications will use the system hostname as a default identifier when they communicate elsewhere. For example, if you're collecting syslog messages at a central server, the messages will all be tagged with the hostname of the originating system. In an ideal world you would probably ignore this (because you don't necessarily want to trust the client), but the default behavior -- if you named all your systems "localhost" -- would result in a bunch of log messages that you wouldn't be able to associate with a specific system.

As other folks have pointed out, the system hostname is also a useful identifier if you find yourself remotely accessing a number of system. If you've got five windows attached to a systems named "localhost" then you're going to have a hard time keeping them straight.

In a similar vein, we try to make the system hostname matches the hostname we use for administrative access to a system. This helps avoid confusion when referring to the system (in email, conversations, documentation, etc).

Regarding DNS:

You want to have proper forward and reverse DNS entries for your applications in order to avoid confusion. You need some forward entry (name -> ip address) for people to be able to access your application conveniently. Having the reverse entry match is useful for an number of reasons -- for example, it helps you correctly identify the application if you find the corresponding ip address in a log.

Note that here I'm talking about "applications" and not "systems", because -- particularly with web servers -- it's common to have multiple ip addresses on a system, associated with different hostnames and services.

Trying to maintain name to ip mappings in your /etc/hosts file quickly becomes difficult as you manage an increasing number of systems. It's very easy to for the local hosts file to fall out of sync with respect to DNS, potentially leading to confusion and in some cases malfunction (because something tries to bind to an ip address that no longer exists on the system, for example).