ExamFinch.com My Study

Study guide

17.2 Configure Hostname Resolution

Practice this exam

Red Hat Certified System Administrator RHCSA

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy

2 Essential Tools: Shell, Redirection & Text Analysis

2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis

3 Essential Tools: Remote Access, Users & Text Editing

3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files

4 Essential Tools: Files, Links & Archives

4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2

5 Essential Tools: Permissions & System Documentation

5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc

6 Manage Software: RPM and Flatpak

6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages

7 Create Simple Shell Scripts

7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts

8 Operate Running Systems: Boot and Recovery

8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access

9 Operate Running Systems: Processes and Tuning

9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles

10 Operate Running Systems: Logs, Services & File Transfer

10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems

11 Configure Local Storage: Partitions and LVM

11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes

12 Configure Local Storage: Mounting and Expansion

12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively

13 Create and Configure File Systems: Local FS and Permissions

13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems

14 Create and Configure File Systems: NFS and autofs

14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs

15 Deploy and Maintain: Scheduling, Services & Targets

15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target

16 Deploy and Maintain: Time, Software Updates & Bootloader

16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader

17 Manage Basic Networking

17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd

18 Manage Users and Groups

18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access

19 Manage Security: Firewall, umask & SSH Keys

19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH

20 Manage Security: SELinux Modes and Contexts

20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts

21 Manage Security: SELinux Ports and Booleans

21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings

17.2 Configure Hostname Resolution

Key Takeaways Explain This Topic AI

Set the system hostname with hostnamectl set-hostname; verify with hostnamectl status and hostname.

Local static name-to-IP mappings belong in /etc/hosts; use them when the task requires a name to resolve without relying only on DNS.

DNS resolver configuration on RHEL 10 is managed through NetworkManager (ipv4.dns / ipv6.dns and related properties)—avoid treating /etc/resolv.conf as a long-lived hand-edited file when NM owns it.

Test resolution with getent hosts, ping, and resolvectl or nmcli device show; prove both hostname identity and name lookup.

Hostname, hosts file, and DNS are related but distinct—EX200 tasks may require one or all three to match the specification.

Last updated: August 2026

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:

System hostname identity — what the machine calls itself ( server1.lab.example.com ).

Local resolution — /etc/hosts entries so names resolve without DNS.

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.

  • Command Role
  • hostnamectl set-hostname NAME Persistent static hostname
  • hostnamectl status Pretty/static/transient overview
  • hostname / uname -n Quick current nodename

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

  • Mechanism When to use
  • /etc/hosts Task gives a specific name↔IP; lab DNS incomplete; must work offline to DNS
  • DNS ( ipv4.dns ) Task says configure nameserver(s); resolve many lab names via classroom DNS
  • Both Common: own hostname in hosts + DNS for the rest

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:

hostnamectl static hostname matches the required identity.

/etc/hosts includes FQDN and short name if both must resolve.

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

hostname NEWNAME only (temporary) without hostnamectl set-hostname — may not persist.

Wrong order in /etc/hosts — name first instead of IP first.

Mapping the hostname to 127.0.0.1 only when the task expects the real interface IP for lab connectivity/scripts.

Hand-editing /etc/resolv.conf only — overwritten by NetworkManager.

Setting DNS on the wrong connection profile — inactive profile does not serve the active NIC.

Forgetting connection up after DNS modify.

Typo in FQDN — server1.lab.example.com vs server1.example.com .

Assuming ping failure is always DNS — could be firewall, routing, or ICMP blocked; use getent hosts to separate resolution from reachability.

Breaking localhost entries in /etc/hosts .

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.