Courseiva
LFCSChapter 12 of 16Objective 5.2

DNS and Hostname Resolution

DNS resolution and hostname settings. Without them, your computer cannot find anything on the internet by name — you would have to type a long string of numbers for every website. For the LFCS exam, you must understand how to configure the system files and commands that control this name-to-address translation.

12 min read
Intermediate
Updated Jul 24, 2026
Reviewed by Johnson Ajibi· Senior Network & Security Engineer · MSc IT Security

A simple way to picture DNS and Hostname Resolution

The Apartment Building Postal System Analogy

7 billion people live on Earth, all sending and receiving mail. If you wanted to send a letter to your friend Sarah who lives in a different city, you wouldn't just write 'Sarah' on the envelope and toss it in a mailbox — the postal system would have no idea where 'Sarah' lives. Instead, you write Sarah's full street address: a unique identifier that tells the postal service exactly which building, floor, and apartment to deliver to.

Now imagine you only know Sarah by her nickname 'Sunny'. You might look up 'Sunny' in a giant phone book that maps nicknames to real street addresses. That phone book is the Domain Name System (DNS). On the internet, every device has a unique numeric address called an IP address (like 192.168.1.1). Humans are bad at remembering strings of numbers, but we are great at remembering names like 'google.com'. DNS is the automated phone book that translates the human-friendly name you type into your browser into the machine-friendly IP address the network needs to find the server hosting the website.

When you type 'www.example.com', your computer first checks its own little address book (the /etc/hosts file). If that fails, it asks a local DNS server — like asking your building's mailroom — which then forwards the request up the chain to the 'main office' (root servers, top-level domain servers) until it finds the authoritative answer: the IP address of 'www.example.com'. The response comes back down the chain, and your browser uses that IP to connect and load the page. Without DNS, we would be memorising strings like '93.184.216.34' just to visit a website.

How It Actually Works

DNS stands for Domain Name System. It is the phone book of the internet. Every device on a network (or the internet) has a unique numeric label called an IP address (Internet Protocol address). There are two main versions: IPv4, which looks like four numbers separated by dots (e.g., 192.168.1.1), and IPv6, which is longer and uses hexadecimal characters (e.g., 2001:db8::1). Humans find it much easier to remember names like 'courseiva.com' than to remember '104.26.14.130'. DNS provides the translation service between these human-readable hostnames and machine-readable IP addresses.

The process starts when you type a URL (Uniform Resource Locator) like 'www.example.com' into a web browser. The browser needs to find the IP address of the server that hosts 'www.example.com'. Before asking any external server, your computer first checks its local cache of recent lookups (to save time) and then checks a special local file called /etc/hosts.

The /etc/hosts file is a simple text file that maps hostnames to IP addresses. On a Linux system, you can edit this file with a text editor like nano or vim. For example, if you add the line '127.0.0.1 localhost', it tells the system that the name 'localhost' should always resolve to the IP address 127.0.0.1 (your own computer). The file is checked before any network DNS query is made. This is useful for testing, blocking websites, or overriding DNS for specific hostnames.

If the hostname is not found in /etc/hosts, the system consults the resolver. The resolver is a set of library routines that perform DNS lookups. Its configuration is in the file /etc/resolv.conf. This file tells the resolver which DNS servers to ask. Typically, it contains lines like 'nameserver 8.8.8.8' (Google's public DNS) or 'nameserver 192.168.1.1' (your router). The resolver sends a query to the first nameserver in the list. If that server does not answer, it tries the next one.

The nameserver then performs a recursive query. It starts by asking one of the 13 root DNS servers. The root server does not know the exact address of 'www.example.com', but it knows which server is responsible for '.com' (the Top-Level Domain, or TLD, server). It directs the query to the TLD server for '.com'. The '.com' TLD server then points to the authoritative nameserver for 'example.com'. That authoritative nameserver holds the actual DNS records, including the A record (which maps a hostname to an IPv4 address) or AAAA record (for IPv6). It returns the IP address back down the chain to your resolver, which caches it for a period of time (called the TTL, or Time To Live) and then returns it to your browser. Your browser then uses that IP to establish a connection and download the webpage.

On Linux, you can manually query DNS using tools like 'dig', 'nslookup', or 'host'. 'dig' is the most powerful — it shows the full response from the nameserver, including all records and timings. 'host' is simpler and gives a concise answer. To see your system's current hostname (the name your machine identifies itself with), you use the 'hostname' or 'hostnamectl' commands. To change the hostname permanently on modern Linux systems, you use 'hostnamectl set-hostname newhostname'. This updates the /etc/hostname file.

A common configuration for DNS resolution on Linux involves the Name Service Switch (NSS) file /etc/nsswitch.conf. This file defines the order in which different databases (like hosts, passwd, group) are queried. For the 'hosts' entry, a typical line looks like: 'hosts: files dns'. This means the system first checks the /etc/hosts file ('files'), and then queries DNS ('dns'). You can also add 'myhostname' or 'mdns' (Multicast DNS) to the list, but for the LFCS exam, the default order of 'files dns' is what you need to know.

The flow of DNS resolution from a user typing a URL to the browser loading the page, showing the checks of /etc/hosts, cache, and the DNS server chain.

Walk-Through

1

User types a URL

The user enters a hostname like 'www.courseiva.com' into a web browser. The browser needs to establish a connection to the server that hosts the site, but it cannot connect using the name — it needs the server's IP address.

2

Check local cache and /etc/hosts

The operating system first checks its local DNS cache (if any) to see if it recently looked up the same hostname. If not found, it reads the /etc/hosts file line by line, looking for a match with the hostname. If there is a matching entry, the corresponding IP address is used immediately, skipping all network queries.

3

Query the resolver

If the hostname is not in /etc/hosts, the system hands the task to the resolver. The resolver reads /etc/resolv.conf to find the IP addresses of the DNS servers to query. It sends a DNS query to the first nameserver listed on UDP port 53.

4

Recursive DNS resolution

The DNS server (if it is recursive) asks the root servers, then the TLD server (e.g., .com), then the authoritative server for the domain (e.g., courseiva.com). The authoritative server returns the IP address for the requested hostname. This answer travels back down the chain to the resolver.

5

Return IP to application and cache

The resolver receives the IP address, caches it for the duration of the TTL, and returns it to the browser. The browser now has the IP address and can open a TCP connection (usually on port 80 for HTTP or 443 for HTTPS) to load the website content.

What This Looks Like on the Job

An IT professional at a medium-sized company called 'WidgetCorp' is responsible for setting up a new internal web application. The development team has created a tool hosted on a server with the static IP address 10.0.0.5. The developers want to access it using the hostname 'devtools.widgetcorp.local'. The IT pro's job is to configure DNS resolution so that every employee's computer can reach this tool by name.

First, the IT pro checks the existing DNS infrastructure. WidgetCorp runs its own internal DNS server (using software like BIND or dnsmasq) on the local network. The IT pro logs into the DNS server and adds a new A record mapping 'devtools.widgetcorp.local' to 10.0.0.5. They also ensure the reverse lookup record (PTR record) is created so administrators can verify the mapping.

For testing purposes, or for a small number of machines, the IT pro could add an entry to the /etc/hosts file on each employee's workstation. They would add '10.0.0.5 devtools.widgetcorp.local' to the file. This is quick for a single machine, but does not scale well to hundreds of computers — imagine having to edit the /etc/hosts file on 200 laptops individually. That is why DNS servers exist.

Next, the IT pro verifies that the workstation's resolver is configured correctly. They check the /etc/resolv.conf file on a test machine. It should contain the internal DNS server's IP address. Sometimes they also add a fallback to a public DNS server like 8.8.8.8 for internet lookups. They run 'dig devtools.widgetcorp.local' to confirm the record is returned correctly. If the dig returns the wrong IP or an error, they check the DNS server logs, the zone file syntax, and the firewall rules between the workstation and the DNS server.

After the DNS server is functioning, the IT pro changes the hostname of the server itself to match its role. On the server with IP 10.0.0.5, they run 'hostnamectl set-hostname devtools-app'. This updates the /etc/hostname file and the transient hostname. They then check that the hostname command returns 'devtools-app'. They also update the /etc/hosts file on the server to include the fully qualified domain name (FQDN) like '10.0.0.5 devtools-app.widgetcorp.local devtools-app' — the first entry is the FQDN, followed by the alias.

Finally, the IT pro documents the changes and tests from multiple employee machines. They also set up a monitoring check that pings the hostname 'devtools.widgetcorp.local' every minute. If the ping fails, an alert is sent. The entire scenario shows that real-world IT work involves a mix of editing configuration files, using diagnostic tools (dig, nslookup, ping), and understanding the difference between local (static) resolution via /etc/hosts and network (dynamic) resolution via DNS.

How LFCS Actually Tests This

The LFCS exam (objective 5.2) tests your ability to configure DNS resolution and hostname settings on a Linux system. You will not be asked to set up a full DNS server (that is a different exam). Instead, you must know how to configure the client side: the files and commands that determine how a Linux machine resolves hostnames and what its own hostname is.

Key topics the exam loves to test:

The /etc/hosts file: You must know its format (IP address first, then hostname, then optional aliases), that it is checked before DNS by default, and how to add entries. A typical question might give you a scenario where you need to override a DNS entry for testing — you would add a line to /etc/hosts.

The /etc/resolv.conf file: You must know that it lists nameservers, that the 'nameserver' keyword is used, and the order of servers matters (the first one is tried first). You may need to edit this file temporarily, but be aware that many modern systems use a resolver like systemd-resolved that manages this file automatically. The exam may test your understanding of the file's direct role.

The /etc/nsswitch.conf file: Specifically the 'hosts' line. You must know that the order 'files dns' means the system checks /etc/hosts first, then DNS. Changing this order changes the lookup behaviour. Questions may ask what happens if a hostname is in both files.

The hostname command: You must know how to view the current hostname ('hostname'), how to change it temporarily (not persistent across reboot) using 'hostname newname', and how to change it permanently using 'hostnamectl set-hostname newname'. The exam may ask which command makes the change survive a reboot.

The /etc/hostname file: This file contains the static hostname. Understanding that 'hostnamectl' writes to this file is key.

Diagnostic tools: You should be able to use 'dig', 'nslookup', and 'host' to query DNS servers. The exam may present a command output and ask you to interpret it — for example, what does 'status: NXDOMAIN' mean? It means the domain does not exist. Understanding common DNS record types such as A (IPv4 address), AAAA (IPv6 address), CNAME (alias), and MX (mail exchange) is helpful.

Common traps the exam sets:

They might ask you to configure a hostname and give you two alternative commands. One command changes the hostname only temporarily (e.g., 'hostname newname'), the other permanently ('hostnamectl set-hostname newname'). Watch for the word 'permanent' or 'persistent' in the question.

They might present a /etc/hosts file with an incorrect format (e.g., hostname before IP address). The exam expects you to recognise the error.

They might ask about the 'order of resolution'. If a hostname is in both /etc/hosts and is resolvable via DNS, which one wins? The answer depends on nsswitch.conf. If it says 'files dns', the /etc/hosts entry wins. If it were 'dns files', DNS would win.

They may ask you to interpret output from 'dig'. For example, you see 'ANSWER: 1' in dig output. You need to know that 'ANSWER' means the number of answer records returned.

Misleading scenario: A server cannot resolve a hostname. One option suggests editing /etc/resolv.conf to add a nameserver, another suggests adding the hostname to /etc/hosts. Both work, but which is the correct approach for a permanent, scalable solution? Adding a nameserver is the proper fix for a DNS configuration; adding to hosts is a temporary fix. The exam may trick you by making the hosts option seem easier.

Memory key for /etc/hosts: 'IP goes first, just like the address goes first on a letter'. For /etc/resolv.conf: 'nameserver then the IP of the server that knows the names'.

Key Takeaways

DNS translates human-friendly hostnames like 'google.com' into machine-readable IP addresses such as '142.250.190.46'.

The /etc/hosts file on Linux is checked before DNS by default, allowing you to override DNS lookups locally.

Use 'hostnamectl set-hostname' for a permanent hostname change; 'hostname' alone only changes it until the next reboot.

The /etc/resolv.conf file lists the IP addresses of your DNS servers, queried in order from first to last.

The nsswitch.conf file controls the order of name resolution — the default 'hosts: files dns' means check /etc/hosts first, then DNS.

To diagnose DNS issues, use 'dig', 'nslookup', or 'host'; 'ping' failure could be due to many factors beyond DNS.

The /etc/hostname file contains the system's static hostname, read at boot time by systemd.

DNS records have a Time To Live (TTL), which determines how long a resolver caches the answer before re-querying.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

/etc/hosts

Static file on the local machine

Checked before DNS queries by default

Manually edited by the system administrator

DNS Server

Distributed network database

Queried after /etc/hosts if no match found

Automatically updated and authoritative for a domain

DNS A Record

Maps a hostname directly to an IPv4 address

Essential for the actual connection to a server

Example: example.com -> 93.184.216.34

DNS CNAME Record

Creates an alias from one hostname to another hostname

Does not hold an IP address itself; the final A record provides the IP

Used for subdomains like 'www' pointing to the root domain

hostname (temporary change)

Changes the hostname only for the current session

Reverts to the original hostname after a reboot

Uses the command 'hostname newname'

hostnamectl set-hostname (permanent change)

Updates /etc/hostname file permanently

Persists across reboots

Uses the command 'hostnamectl set-hostname newname'

dig (DNS lookup tool)

Specifically queries DNS servers and returns detailed records

Does not test network reachability beyond DNS

Useful for diagnosing DNS misconfigurations

ping (network connectivity tool)

Tests if a host is reachable over the network (ICMP)

Does not isolate DNS issues — a failed ping could be due to many reasons

Often misused to test DNS functionality

Watch Out for These

Mistake

I need to edit /etc/resolv.conf to permanently add a DNS server, and it will survive a reboot.

Correct

On modern Linux distributions using NetworkManager or systemd-resolved, /etc/resolv.conf is often a symlink and is overwritten automatically. You should configure DNS through the network manager tool (e.g., nmcli) rather than editing the file directly for persistent changes.

Many tutorials still show manually editing /etc/resolv.conf, and beginners do not realise that newer systems manage this file dynamically.

Mistake

The /etc/hosts file is only for blocking websites or local development; it has no real role in a production network.

Correct

/etc/hosts is used in production environments for many critical purposes: defining the localhost entry, overriding DNS for testing, specifying hostnames for network interfaces that do not have DNS (like in isolated networks), and as a fallback when DNS servers are unreachable.

Newcomers think cloud and professional environments rely only on DNS servers, but many architectures depend on /etc/hosts for resilience.

Mistake

Changing the hostname with the 'hostname' command permanently renames the server.

Correct

The 'hostname' command without any options only sets the hostname for the current session. After a reboot, the original hostname from /etc/hostname is applied unless you also use 'hostnamectl' or edit /etc/hostname directly.

The word 'set' feels permanent, and beginners do not distinguish between runtime (transient) and persistent changes.

Mistake

If I cannot ping google.com, the problem must always be with DNS resolution.

Correct

A failed ping to a hostname could be due to many reasons: the DNS server not being reachable (check /etc/resolv.conf), a firewall blocking ICMP (ping protocol), the remote server being down, or the hostname being wrong. You must use 'dig' or 'nslookup' to isolate whether DNS resolution itself is failing.

Beginners jump to blame DNS because they hear about it often, but network connectivity has many layers.

Mistake

The order in /etc/resolv.conf does not matter; any listed nameserver will be used equally.

Correct

The resolver queries the first nameserver in the list. Only if that server does not respond (timeout) does it try the next one. The order defines the priority.

People assume load balancing or random selection, but it is strictly sequential with timeout.

Mistake

DNS only translates domain names to IP addresses, nothing else.

Correct

DNS also handles reverse lookups (IP to hostname via PTR records), mail routing (MX records), service discovery (SRV records), and aliasing (CNAME records). It is a general-purpose directory service for the internet.

Most introductory materials focus only on A records, leaving beginners unaware of DNS's broader functionality.

Do You Actually Know This?

Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.

Frequently Asked Questions

What is the difference between /etc/hosts and DNS?

/etc/hosts is a static file on your local machine that maps hostnames to IP addresses. DNS is a network-based system that does the same thing but across the entire internet. /etc/hosts is checked first and overrides DNS for the names it contains.

How do I change the hostname permanently on Linux?

Use the command 'sudo hostnamectl set-hostname newhostname'. This updates the /etc/hostname file and the running hostname. The change persists across reboots.

Why does 'nslookup' still work but 'ping google.com' fails?

nslookup queries DNS directly using system libraries, while ping uses the system's general network stack. The issue might be with the network connection, firewall rules blocking ICMP, or the system's routing table — not DNS.

What does 'NXDOMAIN' mean in dig output?

NXDOMAIN means 'Non-Existent Domain'. The DNS server replied that the domain you queried does not exist. This could be because you typed the domain name incorrectly or the domain is truly not registered.

Can I have multiple DNS servers in /etc/resolv.conf?

Yes, you can list multiple nameservers, one per line. The resolver tries them in order: if the first does not respond within a timeout, it tries the next. They are not used for load balancing.

What is the fully qualified domain name (FQDN)?

An FQDN is the complete domain name for a specific host, ending with a dot (e.g., 'www.example.com.'). It includes the hostname, domain, and top-level domain. In /etc/hosts, the FQDN is typically listed first, followed by the short hostname.

Terms Worth Knowing

Keep going

You've finished DNS and Hostname Resolution. Continue through the LFCS study guide to build a complete picture of the exam.

Done with this chapter?