Table of Contents
Understanding DNS and Hostnames
In day to day Linux administration, DNS and hostnames form the bridge between human friendly names and the numeric IP addresses that the system actually uses. At this stage you already know what an IP address is, so the focus here is how Linux uses DNS and hostnames to resolve those addresses in practice.
What a hostname is on a Linux system
A hostname is the human readable name of a machine. It is how the system identifies itself locally and to the network. On a single host you can change the hostname without touching DNS at all, and you can have DNS entries that use names different from the local hostname, although in a well managed environment they usually match.
Linux maintains the hostname in a few places. The current running hostname is kept in memory and can be viewed with the hostname command or hostnamectl. The persistent configuration that survives reboot is usually stored in a simple text file, commonly /etc/hostname on many distributions.
When a Linux system starts, it reads the configured hostname and uses it in logs, in prompts, and in many network services. For example, an SSH server might show the hostname when clients connect. Mail services and some security tools also assume the hostname is set correctly and is globally unique within the environment.
To change the hostname on a modern system that uses systemd, you typically use hostnamectl set-hostname newname. This updates the live hostname and the configuration in one step. On older systems you might also edit /etc/hostname and sometimes an init script or network configuration file. Because other tools sometimes rely on a stable hostname, frequent changes are not recommended in production.
The concept of DNS
DNS, the Domain Name System, is a distributed database that maps domain names to IP addresses and back. It lets a user type something like example.com and have the system find the correct numeric address to connect to. DNS is not a single server but a hierarchy of servers that answer queries about different zones of the global namespace.
From the point of view of a Linux host, DNS is mostly a question and answer service. The local system wants to resolve some name such as www.example.com. It sends a query to a DNS resolver, which then figures out the answer by talking to other DNS servers if it has not cached that information already. The host usually only knows about its local resolver, not the whole DNS hierarchy.
DNS records are stored with a time to live, often written as TTL. This is a number of seconds that tells resolvers how long they can cache a particular answer. A low TTL means changes propagate quickly but increase query load. A high TTL reduces load but means changes take longer to be seen everywhere.
DNS is not guaranteed to update instantly everywhere. The TTL of records controls how long old answers can remain in caches, so changes may appear delayed on different systems.
Name resolution on a Linux host
Name resolution is the process the system uses to turn a hostname or domain name into an IP address. On Linux this process is controlled by the C library resolver, which follows rules defined in configuration files to decide which sources to consult and in which order.
The central configuration file for resolver behavior is /etc/nsswitch.conf. In that file you will find a line that looks similar to:
hosts: files dns
This tells the system that when resolving hostnames, it should consult local files first and then DNS. The main local file it checks is /etc/hosts. This small file can contain manual mappings of hostnames to IP addresses, for example:
127.0.0.1 localhost
127.0.1.1 mymachine
192.0.2.10 internalserver
Entries in /etc/hosts are always checked before going to DNS when files appears before dns in nsswitch.conf. This can be useful for overriding or testing names, but if used carelessly it can create confusing mismatches with what DNS says.
After checking local files, the resolver consults DNS according to the DNS configuration. This split design allows a Linux host to combine simple static mappings with large scale dynamic DNS without complicated logic in each application.
Configuring DNS servers with resolv.conf
Traditionally the file /etc/resolv.conf controls which DNS servers a Linux system queries. Its most important directives are nameserver, search, and domain. A very simple resolv.conf might look like:
nameserver 192.0.2.53
search example.com
Each nameserver line specifies an IP address of a DNS resolver. The search line defines one or more search domains that the resolver appends when you use unqualified names. For example, if search example.com is set and you try to resolve web1, the resolver will also try web1.example.com.
The behavior of resolv.conf can be summarized as follows. When the resolver sees a name with a dot that looks fully qualified, such as www.example.com, it sends that name to the DNS server directly. When it sees a name without dots or with very few dots, the rules in resolv.conf and some internal heuristics control whether search domains are appended. Different C libraries and resolvers can handle this slightly differently.
On modern Linux distributions, /etc/resolv.conf is often dynamically managed by other components, such as systemd-resolved, NetworkManager, or DHCP clients. This means that manual edits can be overwritten when the network changes or the system restarts. Instead of editing the file directly, you usually configure DNS servers in the network manager tools or in the appropriate configuration files for your distribution.
Do not assume /etc/resolv.conf is a permanent manual file. On many systems it is automatically generated. Manual edits may be lost when the network restarts or when DHCP renews the lease.
Forward and reverse DNS lookups
When you resolve a name to an IP address you perform a forward lookup. When you resolve an IP address back to a name you perform a reverse lookup. Linux uses both kinds of lookups in different situations.
A forward lookup asks a question like "what is the IP address for www.example.com". DNS answers with records such as A for IPv4 addresses and AAAA for IPv6 addresses. For example, an A record might say that www.example.com has address 198.51.100.42.
A reverse lookup asks "what name is associated with the IP address 198.51.100.42". This uses a special reverse domain, for IPv4 typically under in-addr.arpa. The answer comes as a PTR record, which returns a hostname. Reverse DNS is not guaranteed to exist for every address, but many services such as mail servers and logging systems prefer having it set.
On a Linux system you can observe both types of lookups with query tools. A forward lookup confirms that names resolve correctly for client access. A reverse lookup helps verify that servers advertise a meaningful name for their address. The presence of a reverse record is also useful in logs because IP addresses then appear with human readable names.
Hostnames, FQDNs, and domain names
A short hostname such as web1 is convenient locally, but DNS usually works with fully qualified domain names, often written as FQDN. An FQDN is the complete name that includes all labels up to the top level domain. For example, web1 might be the short hostname, and web1.example.com the FQDN.
Linux does not strictly enforce any relationship between the kernel hostname and the DNS FQDN. However, in many environments the hostname is set to the short name and the FQDN is derived by combining it with the system's primary DNS domain. Some tools expect an FQDN to be available. For example, hostname -f on many systems attempts to resolve the FQDN using DNS and /etc/hosts.
When dealing with configuration files for network services, you often have to distinguish between these different forms. Using an FQDN in externally visible settings is usually safer because it is globally unique. Using the short hostname is often enough for prompts, internal scripts, and logging on the local machine.
How Linux chooses a name for outbound connections
When a Linux system makes an outbound network connection, for example when it connects to a remote SSH server, it usually does not need to know its own name. The connection is made using IP addresses, and the kernel is satisfied with that. However, many application protocols send or log a name to identify the client.
The name that is used in such cases can come from different places. Some programs query the system hostname directly. Others perform a reverse lookup of the client's IP address, especially on the server side, to display a name instead of an address. Some security tools compare the forward and reverse DNS results as a basic check for name consistency.
As an administrator, this means that setting a sensible hostname and ensuring the DNS or local mappings reflect that name helps with troubleshooting. When log entries refer to clear, consistent hostnames, it is much easier to follow events across multiple systems.
Practical interaction with DNS on Linux
While actual DNS server configuration belongs in a later chapter on network services, you will often need basic command line tools to test and troubleshoot name resolution on a Linux host. These tools query DNS directly and show the raw answers, bypassing some of the layers of abstraction.
Common tools include dig, host, and nslookup. Although none of these are part of the core resolver library, they are widely available. For example, to query a specific record and server, you might use a command like:
dig @192.0.2.53 www.example.com A
This asks the DNS server at 192.0.2.53 for the A record of www.example.com. The output displays the answer, TTL, and other details. This is useful when you suspect a problem with DNS and need to confirm what answer the server is giving, independent of caching on the local machine.
If you simply want to see what address your system currently uses for a name, running getent hosts www.example.com goes through the same resolution process as other applications. It respects /etc/nsswitch.conf, /etc/hosts, and resolv.conf, so it is a good way to see what the system resolver actually returns without relying on shells or external query tools.
Hostname, DNS, and local overrides
In small or isolated environments, DNS may be simple or not present at all. In such cases Linux can still resolve names through /etc/hosts. You can define static entries to give friendly names to important hosts without setting up a full DNS zone.
At the same time, some administrators use /etc/hosts to override public DNS entries temporarily, for example when testing a new server or redirecting traffic for troubleshooting. Because /etc/hosts is checked before DNS when configured that way, it can effectively mask what DNS says.
This interplay between hostname, /etc/hosts, and DNS is a powerful tool but also a common source of confusion. It is important to remember which layer you changed when debugging. Checking /etc/hosts for overrides, confirming the system hostname, and verifying DNS answers separately helps you isolate problems more quickly.
DNS caching and its impact on Linux clients
Linux hosts often rely on caching to speed up name resolution. Sometimes this caching happens on a separate resolver server, such as a company DNS server. Sometimes it happens locally through a stub resolver service. When you change DNS records, cached answers can cause Linux clients to continue using old IP addresses for some time.
On a client system you may encounter caching in different forms. Some distributions run systemd-resolved or a local caching resolver that keeps answers for the configured TTL. Some desktop environments or applications add their own caches. When debugging, you might need to flush these caches or simply wait for TTLs to expire.
Because DNS answers are not updated instantly, you should plan DNS changes with TTL values in mind. For example, if you want to move a service to a new IP address with minimal downtime, you might lower the TTL well before the migration, wait for that lower TTL to propagate, then make the actual IP change. Linux clients will then adopt the new address faster.
Summary of roles
On a Linux system, the local hostname identifies the machine to itself and other systems. DNS provides the global mapping between names and IP addresses. The resolver combines local files and DNS according to rules in nsswitch.conf and configuration in resolv.conf or higher level network tools.
Understanding how these pieces fit together helps you interpret logs that mention hostnames, configure services with the correct names, and troubleshoot connectivity issues that might actually be the result of name resolution problems and not network routing issues themselves.