RED HAT ENTERPRISE LINUX

Configure Hostname
Resolution

Configure hostname resolution

CIS126RH | RHEL System Administration 1
Mesa Community College

Hostname resolution translates human-readable names like servera.example.com into IP addresses. Every networked application depends on it — SSH, web browsers, NFS, Kerberos, and systemd logs all use name resolution. RHEL 9 resolves names using two mechanisms: the local /etc/hosts file for static mappings, and DNS servers configured via NetworkManager or /etc/resolv.conf. The order in which these are consulted is controlled by /etc/nsswitch.conf. All three files are tested on the RHCSA exam.

Learning Objectives

1. Explain the name resolution process — Describe the order in which RHEL 9 consults resolution sources and the role of /etc/nsswitch.conf
2. Configure static name resolution with /etc/hosts — Add, modify, and verify entries in /etc/hosts for local hostname-to-IP mappings
3. Configure DNS servers — Set DNS server addresses persistently using nmcli and verify the resulting /etc/resolv.conf
4. Test and troubleshoot hostname resolution — Use dig, host, nslookup, and getent hosts to verify that names resolve correctly

How Name Resolution Works

When an application needs to resolve a hostname, the system follows a defined order of sources. The first source that returns an answer wins.

1. Local cache — systemd-resolved or nscd cache; avoids repeated lookups
2. /etc/hosts — static file checked before DNS; entries here always override DNS for the same name
3. DNS servers — queried via the servers listed in /etc/resolv.conf; set by NetworkManager from the connection profile
4. Other sources — NIS, LDAP, mDNS (if configured)

/etc/hosts: Static Name Resolution

The /etc/hosts file provides immediate, static hostname-to-IP mappings that take precedence over DNS.

# View the current /etc/hosts file
$ cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

192.168.1.10  servera.example.com  servera
192.168.1.11  serverb.example.com  serverb

# File format: IP_ADDRESS FQDN [ALIASES...]
# Lines beginning with # are comments
# Multiple aliases can follow the FQDN on the same line

# Add an entry (edit as root)
$ sudo vim /etc/hosts
# Append: 192.168.1.20  database.example.com  database

# Or append non-interactively
$ echo "192.168.1.20  database.example.com  database" | \
  sudo tee -a /etc/hosts

/etc/hosts Entry Format

Each non-comment line in /etc/hosts follows a specific format. Understanding it prevents common errors.

# Format:
# IP_ADDRESS   CANONICAL_HOSTNAME   [ALIAS1] [ALIAS2] ...

# IPv4 entries
192.168.1.10   servera.example.com   servera
10.0.0.1       router.lab.local      router    gw

# IPv6 entry
2001:db8::10   servera.example.com   servera

# A host can have BOTH an IPv4 and IPv6 entry
192.168.1.10   servera.example.com   servera
2001:db8::10   servera.example.com   servera

# Test that the entry resolves (no network needed)
$ getent hosts servera
192.168.1.10   servera.example.com

$ getent hosts servera.example.com
192.168.1.10   servera.example.com

# Reverse lookup via /etc/hosts
$ getent hosts 192.168.1.10
192.168.1.10   servera.example.com

/etc/resolv.conf and DNS Configuration

/etc/resolv.conf tells the resolver which DNS servers to query. On RHEL 9, it is managed by NetworkManager — do not edit it directly.

# View the current DNS configuration
$ cat /etc/resolv.conf
# Generated by NetworkManager
search example.com
nameserver 192.168.1.53
nameserver 8.8.8.8

# resolv.conf key directives:
# nameserver  — DNS server IP (up to 3, one per line)
# search      — domain suffixes appended to short hostnames
# domain      — single default search domain

# Check if resolv.conf is managed by NetworkManager
$ ls -la /etc/resolv.conf
lrwxrwxrwx. 1 root root 37 May 25 07:00 /etc/resolv.conf ->
    ../run/systemd/resolve/stub-resolv.conf
# On RHEL 9, /etc/resolv.conf may be a symlink to systemd-resolved

Configuring DNS Servers with nmcli

DNS servers are set in the NetworkManager connection profile using nmcli connection modify.

# Set DNS servers for an IPv4 connection
$ sudo nmcli connection modify ens3 \
    ipv4.dns "192.168.1.53,8.8.8.8"

# Set a DNS search domain
$ sudo nmcli connection modify ens3 \
    ipv4.dns-search "example.com"

# Set both in one command
$ sudo nmcli connection modify ens3 \
    ipv4.dns "192.168.1.53" \
    ipv4.dns-search "example.com"

# Apply the change
$ sudo nmcli connection up ens3

# Verify — resolv.conf should now show the new nameservers
$ cat /etc/resolv.conf
# Generated by NetworkManager
search example.com
nameserver 192.168.1.53

# Also verify via nmcli
$ nmcli connection show ens3 | grep dns
ipv4.dns:    192.168.1.53
ipv4.dns-search: example.com

/etc/nsswitch.conf: Resolution Order

The Name Service Switch configuration file defines the order in which resolution sources are consulted for each type of lookup.

# View the hosts line in nsswitch.conf
$ grep ^hosts /etc/nsswitch.conf
hosts:      files dns myhostname

# Breakdown of the default hosts line:
# files      → check /etc/hosts first
# dns        → then query DNS (via /etc/resolv.conf)
# myhostname → resolve the local system hostname last

# Full nsswitch.conf excerpt
$ cat /etc/nsswitch.conf
passwd:     sss files systemd
shadow:     files sss
group:      sss files systemd
hosts:      files dns myhostname
networks:   files dns
protocols:  files
services:   files sss
...

Testing Resolution: dig and host

dig and host are DNS query tools that bypass /etc/hosts and query DNS servers directly.

# Install dig and host (from bind-utils)
$ sudo dnf install -y bind-utils

# Query DNS for an A record (IPv4)
$ dig servera.example.com
;; ANSWER SECTION:
servera.example.com.  300  IN  A  192.168.1.10

# Query a specific DNS server
$ dig @192.168.1.53 servera.example.com

# Shorter output (just the answer)
$ dig +short servera.example.com
192.168.1.10

# Query for AAAA record (IPv6)
$ dig AAAA servera.example.com

# Reverse DNS lookup
$ dig -x 192.168.1.10

# host command — simpler output
$ host servera.example.com
servera.example.com has address 192.168.1.10

$ host 192.168.1.10
10.1.168.192.in-addr.arpa domain name pointer servera.example.com.

Testing the Full Resolution Stack: getent

getent hosts tests the complete resolution stack including /etc/hosts — the most reliable verification tool.

# getent honours /etc/hosts AND nsswitch.conf order
$ getent hosts servera.example.com
192.168.1.10  servera.example.com

# If the name is in /etc/hosts, getent returns it without DNS
$ getent hosts database
192.168.1.20  database.example.com

# getent shows no output if the name cannot be resolved
$ getent hosts nonexistent.example.com
# (empty output = cannot resolve)

# nslookup — interactive DNS query tool (older)
$ nslookup servera.example.com
Server:         192.168.1.53
Address:        192.168.1.53#53

Name:   servera.example.com
Address: 192.168.1.10

# nslookup with specific server
$ nslookup servera.example.com 8.8.8.8

DNS Search Domains

The search directive in /etc/resolv.conf allows short hostnames to be resolved without typing the full FQDN.

# Example resolv.conf with search domain
search example.com
nameserver 192.168.1.53

# With search example.com, these two resolve to the same address:
$ ping servera               # resolver tries servera.example.com
$ ping servera.example.com   # full FQDN — no search needed

# Set search domain persistently with nmcli
$ sudo nmcli connection modify ens3 \
    ipv4.dns-search "example.com"
$ sudo nmcli connection up ens3

# Multiple search domains (tried in order)
$ sudo nmcli connection modify ens3 \
    ipv4.dns-search "example.com,lab.local"

# Verify the search domain is in resolv.conf
$ grep search /etc/resolv.conf
search example.com

Practical Resolution Troubleshooting

When a hostname does not resolve, a systematic approach finds the cause.

# Step 1: Check /etc/hosts for a static entry
$ grep servera /etc/hosts

# Step 2: Check what DNS servers are configured
$ cat /etc/resolv.conf

# Step 3: Test DNS server reachability
$ ping -c 2 192.168.1.53    # can we reach the DNS server?

# Step 4: Query DNS directly
$ dig @192.168.1.53 servera.example.com

# Step 5: Test full resolution stack
$ getent hosts servera.example.com

# Step 6: Check nsswitch.conf order
$ grep ^hosts /etc/nsswitch.conf

systemd-resolved

RHEL 9 can use systemd-resolved as a caching DNS stub resolver — an additional layer between applications and the external DNS server.

# Check if systemd-resolved is running
$ systemctl status systemd-resolved

# Show resolved's DNS configuration and cache status
$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
      DNS Servers: 192.168.1.53
...
Link 2 (ens3)
    DNS Servers: 192.168.1.53

# Test resolution via systemd-resolved
$ resolvectl query servera.example.com
servera.example.com: 192.168.1.10

# Flush the DNS cache
$ sudo resolvectl flush-caches

# Show DNS statistics
$ resolvectl statistics

Hostname Resolution Quick Reference

Common Mistakes

Complete Configuration Example

The exam scenario: configure the system to resolve servera.example.com statically, use 192.168.1.53 as the DNS server, and use example.com as the search domain.

# Step 1: Add static entry for servera to /etc/hosts
$ echo "192.168.1.10  servera.example.com  servera" | \
  sudo tee -a /etc/hosts

# Step 2: Configure DNS server and search domain via nmcli
$ sudo nmcli connection modify ens3 \
    ipv4.dns "192.168.1.53" \
    ipv4.dns-search "example.com"

# Step 3: Activate the connection
$ sudo nmcli connection up ens3

# Step 4: Verify static entry
$ getent hosts servera
192.168.1.10  servera.example.com

# Step 5: Verify DNS and search domain
$ cat /etc/resolv.conf
search example.com
nameserver 192.168.1.53

# Step 6: Test DNS query
$ dig +short serverb.example.com
192.168.1.11

Knowledge Check

Answer these before moving to the next slide.

1. What is the default name resolution order on RHEL 9, and which file controls it?
2. Write the /etc/hosts entry to map IP 10.0.0.20 to the hostname appserver.lab.local with alias appserver.
3. Write the nmcli commands to configure the connection ens3 to use DNS server 10.0.0.53 and search domain lab.local.
4. You added an entry for appserver.lab.local to /etc/hosts. Write the command that will confirm the entry is working, and explain why dig is not the right tool here.
5. A user reports that ping appserver works but reaches the wrong IP. What is the most likely cause, and how do you diagnose it?
6. What does the search directive in /etc/resolv.conf do? Write the nmcli command that sets it persistently.

Knowledge Check — Answers

1. The default order is files → dns → myhostname: check /etc/hosts first, then DNS servers from /etc/resolv.conf, then the local system hostname. The order is defined by the hosts: line in /etc/nsswitch.conf.
2. 10.0.0.20 appserver.lab.local appserver
   The FQDN (appserver.lab.local) must immediately follow the IP address; the alias (appserver) comes after the FQDN.
3. sudo nmcli connection modify ens3 ipv4.dns "10.0.0.53" ipv4.dns-search "lab.local"
   Then: sudo nmcli connection up ens3 to apply.
4. getent hosts appserver.lab.local — this command honours /etc/hosts and the nsswitch.conf resolution order, so it returns the /etc/hosts entry if present. dig queries DNS directly and completely bypasses /etc/hosts, so it would return the DNS answer (or nothing if the name is not in DNS) — it does not test static entries.
5. The most likely cause is a stale or incorrect entry in /etc/hosts that overrides DNS (since files comes before dns in nsswitch.conf). Diagnose with: grep appserver /etc/hosts — check whether the IP address there matches the expected one. Fix by correcting or removing the /etc/hosts entry.
6. The search directive appends a domain name to short hostnames before querying DNS — so ping appserver automatically becomes a query for appserver.lab.local. Set it persistently: sudo nmcli connection modify ens3 ipv4.dns-search "lab.local" then sudo nmcli connection up ens3.

Key Takeaways

1. Resolution order: /etc/hosts first, then DNS. The hosts: files dns line in /etc/nsswitch.conf controls the order. /etc/hosts entries always override DNS for the same name. Changes to /etc/hosts take effect immediately — no restart needed.
2. /etc/hosts format: IP FQDN [aliases]. The FQDN must immediately follow the IP. Aliases follow after the FQDN. Both IPv4 and IPv6 entries can exist for the same hostname. Test with getent hosts NAME — not dig.
3. Set DNS servers persistently with nmcli, not by editing /etc/resolv.conf. nmcli con mod CONNAME ipv4.dns "DNS1" and ipv4.dns-search "DOMAIN" then nmcli con up CONNAME. Direct edits to /etc/resolv.conf are overwritten by NetworkManager.
4. Use getent to test the full stack; use dig to test DNS only. getent hosts NAME checks /etc/hosts and DNS in nsswitch.conf order — it simulates what applications see. dig NAME queries DNS directly and skips /etc/hosts — use it to test DNS server responses specifically.

Graded Lab

• Run cat /etc/hosts and cat /etc/resolv.conf to record the current state. Run grep ^hosts /etc/nsswitch.conf to confirm the resolution order.
• Add an entry to /etc/hosts mapping 192.168.1.100 to labserver.example.com with alias labserver. Immediately verify with getent hosts labserver and confirm the IP address and canonical name are correct.
• Configure ens3 to use the classroom DNS server provided by the instructor using nmcli connection modify with ipv4.dns and ipv4.dns-search "example.com". Activate the connection and verify the updated /etc/resolv.conf.
• Demonstrate the files-before-dns precedence: add a /etc/hosts entry for a name that also exists in DNS but with a different IP. Run both getent hosts NAME and dig NAME — observe that getent returns the /etc/hosts IP and dig returns the DNS IP. Remove the /etc/hosts entry and confirm getent now returns the DNS answer.
• Install bind-utils with dnf. Use dig +short NAME to query two hostnames that exist in DNS (provided by instructor). Use dig -x IP to perform a reverse lookup on each address.
• Reboot the system. Confirm that the /etc/hosts entry persists (getent hosts labserver) and that /etc/resolv.conf still shows the correct DNS server (confirming nmcli was used, not direct edit).

Next: Getting Help from Local Documentation