17.2 Configure Hostname Resolution

17.2 Configure Hostname Resolution

Quick Answer: Set the host’s own name with hostnamectl set-hostname. Map names to IPs locally in /etc/hosts. Point the system at DNS servers with NetworkManager (nmcli connection modify … ipv4.dns … then connection up). Verify with hostnamectl, getent hosts, and ping. Do not assume editing /etc/resolv.conf by hand will persist under NetworkManager.

What “hostname resolution” means on EX200

Tasks under this skill usually involve one or more of:

1. System hostname identity — what the machine calls itself (server1.lab.example.com).
2. Local resolution — /etc/hosts entries so names resolve without DNS.
3. DNS client configuration — which recursive resolvers the host queries.

Examples of lab language:

• “Set the hostname to serverX.example.com.”
• “Ensure utility.lab.example.com resolves to 172.25.250.254.”
• “Configure DNS server 172.25.250.254 for the primary connection.”

Passing means the name behaves correctly after reboot, not only in an interactive shell where you exported a temporary hostname.

Set and verify the system hostname

hostnamectl
hostname
hostname -f    # FQDN when resolvable via hosts/DNS

Set a static hostname (preferred, persistent):

sudo hostnamectl set-hostname server1.lab.example.com
hostnamectl status
hostname

hostnamectl writes the static hostname (commonly /etc/hostname) and updates the runtime hostname. No separate “enable hostname service” step is required for the name itself.

Transient hostname can differ in some DHCP environments; for EX200, set the static hostname the task names and verify it survives reboot.

Pretty hostname vs static

sudo hostnamectl set-hostname "Server One" --pretty   # display label
sudo hostnamectl set-hostname server1.lab.example.com # static (default)

Exam tasks almost always want the static (and usually FQDN-style) name, not only a pretty description.

/etc/hosts — local static mappings

/etc/hosts maps names to IP addresses before or instead of relying solely on DNS (order controlled by nsswitch; traditionally files dns for hosts).

getent hosts server1.lab.example.com
cat /etc/hosts

Typical pattern after setting a hostname—map the host’s own IP and name:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

172.25.250.11   server1.lab.example.com server1

Also common: map other lab systems the task names:

172.25.250.254  utility.lab.example.com utility
172.25.250.10   classroom.example.com

sudo vim /etc/hosts
# or carefully:
echo "172.25.250.254 utility.lab.example.com utility" | sudo tee -a /etc/hosts
getent hosts utility.lab.example.com
ping -c 1 utility.lab.example.com

Rules of thumb:

• Put IP first, then FQDN, then optional short aliases.
• Do not remove localhost lines casually.
• Prefer the address the task associates with that host (often the static IP you set in 17.1).
• /etc/hosts is file-based persistence—it survives reboot without NetworkManager.

hosts vs DNS

If a name must resolve and DNS is wrong or unreachable, a correct hosts line still saves the objective.

DNS via NetworkManager (preferred)

On RHEL with NetworkManager, DNS servers are connection properties:

sudo nmcli connection modify ens192 \
  ipv4.dns "172.25.250.254" \
  ipv4.dns-search "lab.example.com"

sudo nmcli connection up ens192

Multiple DNS servers:

sudo nmcli connection modify ens192 ipv4.dns "172.25.250.254 8.8.8.8"
sudo nmcli connection up ens192

IPv6 DNS when required:

sudo nmcli connection modify ens192 ipv6.dns "2001:db8::53"
sudo nmcli connection up ens192

Inspect what NM believes:

nmcli -f ipv4.dns,ipv4.dns-search,ipv6.dns connection show ens192
nmcli device show ens192 | egrep 'IP4.DNS|IP6.DNS|DOMAIN'

/etc/resolv.conf reality check

Historically admins edited /etc/resolv.conf directly:

nameserver 172.25.250.254
search lab.example.com

On NetworkManager-managed systems, /etc/resolv.conf is often generated or pointed at a stub resolver. Hand edits can be overwritten when the connection goes up or when NM restarts.

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Exam practice: set DNS with nmcli (or nmtui), reapply the connection, then read /etc/resolv.conf or nmcli device show to confirm—do not rely on a one-time manual resolv.conf edit as your only change unless the environment clearly uses unmanaged networking (unusual for standard RHEL EX200 networking objectives).

If you must inspect resolver behavior:

resolvectl status 2>/dev/null || true
getent hosts classroom.example.com
ping -c 2 classroom.example.com

nsswitch and getent

grep hosts /etc/nsswitch.conf
# often: hosts: files dns myhostname

getent hosts NAME uses the same Name Service Switch path applications use—better proof than assuming only ping or only DNS tools.

getent hosts server1.lab.example.com
getent ahosts utility.lab.example.com

Short name vs FQDN

Tasks may use server1 or server1.lab.example.com. Ensure:

1. hostnamectl static hostname matches the required identity.
2. /etc/hosts includes FQDN and short name if both must resolve.
3. ipv4.dns-search includes the lab domain if short names should expand via DNS search list.

sudo nmcli connection modify ens192 ipv4.dns-search "lab.example.com example.com"
sudo nmcli connection up ens192

Exam workflows

Workflow A — Set hostname and self-map in hosts

sudo hostnamectl set-hostname server1.lab.example.com
# Ensure IP from 17.1 is known, e.g. 172.25.250.11
sudo bash -c 'grep -q server1.lab.example.com /etc/hosts || \
  echo "172.25.250.11 server1.lab.example.com server1" >> /etc/hosts'
hostnamectl
getent hosts server1.lab.example.com

Workflow B — Map a utility host

echo "172.25.250.254 utility.lab.example.com utility" | sudo tee -a /etc/hosts
getent hosts utility
ping -c 1 utility.lab.example.com

Workflow C — Configure DNS on the connection

sudo nmcli connection modify ens192 \
  ipv4.method manual \
  ipv4.addresses 172.25.250.11/24 \
  ipv4.gateway 172.25.250.254 \
  ipv4.dns 172.25.250.254 \
  ipv4.dns-search lab.example.com
sudo nmcli connection up ens192
nmcli -f IP4.DNS device show ens192
getent hosts classroom.example.com

(Address lines shown together because many tasks combine IP + DNS on one profile.)

Workflow D — Verify after change

hostnamectl status
cat /etc/hosts
nmcli -g ipv4.dns connection show ens192
getent hosts server1.lab.example.com
ping -c 1 $(hostname)

Common traps

1. hostname NEWNAME only (temporary) without hostnamectl set-hostname — may not persist.
2. Wrong order in /etc/hosts — name first instead of IP first.
3. Mapping the hostname to 127.0.0.1 only when the task expects the real interface IP for lab connectivity/scripts.
4. Hand-editing /etc/resolv.conf only — overwritten by NetworkManager.
5. Setting DNS on the wrong connection profile — inactive profile does not serve the active NIC.
6. Forgetting connection up after DNS modify.
7. Typo in FQDN — server1.lab.example.com vs server1.example.com.
8. Assuming ping failure is always DNS — could be firewall, routing, or ICMP blocked; use getent hosts to separate resolution from reachability.
9. Breaking localhost entries in /etc/hosts.
10. Changing hostname but not updating service certs/configs that embed old names (less common on EX200, but scripts may check hostname).

Relationship to other sections

• 17.1: Correct interface IP often appears in /etc/hosts next to your hostname.
• 17.3: NetworkManager must be running for NM-based DNS to apply.
• NFS/SSH chapters: name resolution failures look like “host unknown” before mount or login.
• Security: firewall does not replace DNS; open ports still need correct names/IPs in client configs.

Section checkpoint

You should set a persistent hostname with hostnamectl set-hostname, maintain accurate /etc/hosts mappings (IP, FQDN, aliases), configure DNS through NetworkManager (ipv4.dns / search domains + nmcli connection up), understand that /etc/resolv.conf may be managed, and verify with hostnamectl, getent hosts, and connectivity tests. That is the EX200 bar for hostname resolution on RHEL 10.