A Linux server can communicate perfectly at the IP layer and still fail when you type a hostname. The missing piece is name resolution: the process that turns a name such as example.com into an IP address that networking software can actually use.
DNS is central to that process, but Linux name resolution is not simply “read /etc/resolv.conf and ask DNS.” Applications normally use the operating system’s name-resolution facilities, which may consult local files, system services, and DNS according to the machine’s configuration.
When an application on Linux needs the IP address for a hostname, the system follows its configured name-resolution path. On many systems, the Name Service Switch configuration in /etc/nsswitch.conf determines which sources are consulted and in what order.
The answer may come from a local source such as /etc/hosts, from a local resolver service, or from DNS. The file /etc/resolv.conf commonly provides resolver information such as DNS server addresses and search domains, although modern distributions may manage that file through another networking or resolver service.
- What name resolution means and why applications need it.
- How DNS fits into the broader Linux hostname-resolution process.
- What /etc/nsswitch.conf, /etc/hosts, and /etc/resolv.conf do.
- Why getent is useful when testing what normal applications may resolve.
- How to inspect DNS configuration without changing the system.
- How to distinguish a DNS problem from a general network problem.
- 🌐 What Is Name Resolution?
- Hostname
- Resolver
- IP Address
- 🧠 The Mental Model: DNS Is One Part of Resolution
- 🗂️ The Three Files You Should Recognize
- 1. /etc/nsswitch.conf
- 2. /etc/hosts
- 3. /etc/resolv.conf
- 🔄 What Happens When a Program Resolves a Name?
- The application requests address information
- The configured lookup policy is applied
- A local source may answer first
- DNS is used when the configured path requires it
- The application receives address information
- 📡 Where systemd-resolved Fits In
- 🔍 Why getent Is So Useful
- 🧪 Mini Lab: Inspect Name Resolution Safely
- Step 1 — Inspect the host lookup policy
- Step 2 — Check for a local mapping
- Step 3 — Inspect resolver configuration
- Step 4 — Test system name resolution
- Step 5 — Inspect systemd-resolved if applicable
- 🛠️ DNS Failure or Network Failure?
- ⚠️ Common Mistakes
- 💡 A Practical Troubleshooting Order
- ✅ Knowledge Check
🌐 What Is Name Resolution?
Computers route network traffic using addresses, not human-friendly domain names. An application may be given example.com, but before it can open an IP connection it normally needs one or more corresponding IP addresses.
Name resolution is the broader process of obtaining that information. DNS, the Domain Name System, is one possible source used during that process.
This distinction matters because a hostname can sometimes resolve even when no external DNS query is made. A local entry, a resolver cache, or another configured name service may provide the answer first.
Hostname
A human-readable name such as example.com that an application wants to use.
Resolver
The system mechanisms that determine where to look for information about that name.
IP Address
An IPv4 or IPv6 address returned for the name and usable by network software.
🧠 The Mental Model: DNS Is One Part of Resolution
A useful beginner model is to separate name resolution from DNS lookup.
When a normal Linux application requests an address for a hostname, the system can use the Name Service Switch, or NSS, to determine which configured sources should participate in resolving host names. The relevant policy is represented by the hosts: entry in /etc/nsswitch.conf.
A simple NSS configuration might contain a line resembling:
hosts: files dnsConceptually, files means that local host information such as /etc/hosts is considered, while dns enables DNS-based resolution.
Do not assume every Linux machine has exactly this line. Modern distributions can include additional NSS modules and local resolver services, so the actual hosts: line is the configuration that matters on the machine you are investigating.
When troubleshooting, ask “How is this application resolving the name?” before asking only “Does DNS work?” Those questions overlap, but they are not identical.
🗂️ The Three Files You Should Recognize
| File | Main Role | Question It Helps Answer |
|---|---|---|
| /etc/nsswitch.conf | Defines name-service sources and their lookup order for several databases, including hosts. | Where should the system look for host information? |
| /etc/hosts | Stores local hostname-to-address mappings. | Is this hostname defined locally? |
| /etc/resolv.conf | Provides resolver configuration such as name servers and search domains in the traditional resolver model. | Which DNS resolver information is configured? |
1. /etc/nsswitch.conf
The Name Service Switch is broader than DNS. It controls lookup sources for several kinds of system information. For hostname resolution, focus on the line beginning with hosts:.
You can inspect it safely:
grep '^hosts:' /etc/nsswitch.confThe exact output varies by distribution and configuration. You might see files, dns, resolve, myhostname, or other modules.
2. /etc/hosts
/etc/hosts is a local database of static address-to-name mappings. A simple illustrative entry looks like this:
192.0.2.10 app.example.testIf the machine’s NSS configuration gives local files appropriate priority, a matching local entry can satisfy the lookup without asking an external DNS server.
This is why changing public DNS does not necessarily change what every process on a particular server resolves: local resolution policy can affect the result.
3. /etc/resolv.conf
The traditional Linux resolver configuration is stored in /etc/resolv.conf. A simplified example might look like:
nameserver 192.0.2.53
search example.testThe nameserver directive identifies a DNS server address for the resolver. The search directive defines suffixes that may be tried when resolving suitable non-fully-qualified names.
The exact contents of your file may be different, and on some modern systems /etc/resolv.conf is generated or linked to a file managed by software such as NetworkManager, systemd-resolved, or another networking service.
Do not immediately edit /etc/resolv.conf just because DNS appears broken. First determine who manages it. A manual change to a generated file may be overwritten, and it may not address the real source of the configuration.
🔄 What Happens When a Program Resolves a Name?
Imagine an application needs to connect to app.example.test. The exact implementation depends on the application and system configuration, but the normal system-resolution path can be understood in stages.
The application requests address information
The application supplies a hostname to the operating system’s name-resolution interfaces rather than manually translating the name into an IP address itself.
The configured lookup policy is applied
For applications using the standard GNU C Library name-service mechanisms, the hosts: configuration in /etc/nsswitch.conf determines which configured sources are consulted and their order.
A local source may answer first
If local files or another local resolver module are configured before DNS and can answer the query, the process may not need a conventional external DNS lookup.
DNS is used when the configured path requires it
The resolver sends or delegates the DNS request according to the machine’s resolver configuration. On a traditional setup, /etc/resolv.conf identifies the name servers. On systems using a local resolver service, the path can include that service first.
The application receives address information
The result can contain IPv4 addresses, IPv6 addresses, or both. The application can then attempt a network connection using the returned address information.
📡 Where systemd-resolved Fits In
Some Linux systems use systemd-resolved, a system service that provides network name resolution and can maintain DNS configuration on a per-interface basis.
On such systems, /etc/resolv.conf may point to a local stub resolver rather than directly listing the upstream DNS servers you expect to see. That does not mean the machine is limited to a local DNS source. The local resolver can receive the application’s request and forward it according to its configured upstream and per-link DNS information.
If the resolvectl command is available and systemd-resolved is in use, this command can display resolver state:
resolvectl statusDepending on the configuration, the output can show global and per-link DNS information, which is especially useful on machines with multiple network interfaces, VPNs, or interface-specific DNS settings.
Seeing 127.0.0.53 in /etc/resolv.conf on a system using systemd-resolved does not by itself identify the final upstream DNS server. It represents the local systemd-resolved stub listener. Inspect the resolver service’s configuration to understand where queries can go next.
🔍 Why getent Is So Useful
When your question is “What address can a normal system lookup obtain for this hostname?”, getent is a valuable diagnostic tool on systems that provide it.
The command queries databases supported by the system’s Name Service Switch configuration. For host resolution, you can use:
getent ahosts example.comThis is different from asking only a specific DNS server. It helps test the host-resolution path that uses the system’s configured name-service mechanisms.
For a simpler hosts-database lookup, you can also use:
getent hosts example.comOutput depends on the host, network, resolver configuration, available address families, and current DNS data. Do not expect a particular IP address from this lesson.
🧪 Mini Lab: Inspect Name Resolution Safely
Goal: identify the main components involved in hostname resolution on your Linux machine without changing any configuration.
Step 1 — Inspect the host lookup policy
Read the hosts: line:
grep '^hosts:' /etc/nsswitch.confWhat to observe: note the source names and their order. Do not worry if your output contains more entries than a simple files dns example.
Step 2 — Check for a local mapping
Inspect the local hosts file:
cat /etc/hostsWhat to observe: look for local names such as localhost and any administrator-defined host mappings.
Step 3 — Inspect resolver configuration
Read the resolver file:
cat /etc/resolv.confWhat to observe: look for nameserver, search, and options directives. Also consider whether the file indicates that another service manages it.
Step 4 — Test system name resolution
Ask the system’s NSS-based lookup mechanism for addresses:
getent ahosts example.comHow to interpret it: if addresses are returned, the system’s configured host-resolution path was able to resolve the name. This does not prove that a direct external DNS query occurred because another configured source may have participated.
Step 5 — Inspect systemd-resolved if applicable
If your system uses systemd-resolved and provides resolvectl, inspect its status:
resolvectl statusWhat to observe: compare global DNS information with DNS configuration associated with individual network links.
🛠️ DNS Failure or Network Failure?
One of the most useful troubleshooting skills is separating name resolution from IP connectivity.
Suppose an application cannot reach a service by hostname. There are at least two fundamentally different possibilities:
| Observation | What It Suggests | Next Area to Inspect |
|---|---|---|
| Hostname lookup fails | The name-resolution path needs investigation. | NSS policy, local host entries, resolver service, DNS configuration. |
| Name resolves, but connection fails | Resolution may be working; the failure may occur later. | Routes, firewall rules, service availability, ports, network path. |
| Local mapping works but expected DNS result differs | A local source may be taking precedence. | /etc/hosts and the hosts line in nsswitch.conf. |
| Resolver configuration shows a local stub | A local resolver service may sit between applications and upstream DNS. | Resolver service status and per-link DNS configuration. |
This gives you a much better troubleshooting sequence than immediately changing DNS servers.
⚠️ Common Mistakes
DNS is a major source of hostname information, but Linux can use local files and other configured name-service modules. A successful hostname lookup does not automatically prove that an external DNS query occurred.
A resolver service or network manager may generate the file or place a local stub address in it. Inspect the system’s actual resolver architecture before drawing conclusions from one file.
Changing DNS settings too early can hide the original problem. First inspect NSS, local host mappings, resolver configuration, and the result of a normal system lookup.
Name resolution only provides address information. Routing, firewall policy, the destination port, and the remote service can still prevent a connection.
Linux systems can differ in their NSS modules, network managers, and resolver services. Learn the concepts first, then inspect the actual configuration on the machine in front of you.
💡 A Practical Troubleshooting Order
When a hostname unexpectedly fails on a Linux server, investigate from the application-facing side toward DNS rather than changing settings at random.
- Use getent to see whether the system can resolve the hostname through its configured mechanisms.
- Inspect the hosts: line in /etc/nsswitch.conf.
- Check whether /etc/hosts contains a relevant local mapping.
- Inspect /etc/resolv.conf without assuming it is manually maintained.
- If a local resolver such as systemd-resolved is involved, inspect that service’s actual DNS state.
- Once resolution succeeds, troubleshoot routing, ports, firewalls, and the application separately if the connection still fails.
The most important troubleshooting boundary is this: resolving an address and reaching that address are separate operations. DNS can succeed while the connection fails, and IP connectivity can work while hostname resolution fails.
✅ Knowledge Check
- Why is “name resolution” a broader concept than “DNS lookup” on Linux?
- What does the hosts: line in /etc/nsswitch.conf help determine?
- Why might a hostname resolve without a conventional external DNS query?
- Why should you avoid immediately editing /etc/resolv.conf when troubleshooting?
- What is useful about testing a hostname with getent?
- If a hostname resolves to an IP address but the application still cannot connect, what does that tell you?
🎓 Check Your Answers
- Name resolution describes the overall process of finding address information for a name. DNS can participate in that process, but local files and other configured name-service mechanisms may also provide an answer.
- The hosts: line defines the configured sources used for host-name information and their lookup policy. It helps explain why the same hostname can be resolved from a local source on one machine and through DNS on another.
- A configured local source may already know the answer. For example, an entry in /etc/hosts can satisfy a lookup when the NSS configuration causes that source to be consulted successfully.
- The file may be generated or linked to configuration maintained by a resolver or network-management service. Editing it directly can therefore be temporary or target the wrong configuration layer.
- getent uses databases supported by the system’s Name Service Switch libraries. That makes it useful for observing the configured system-resolution path rather than testing only a manually selected DNS server.
- It shows that name resolution can produce address information, but it does not prove the destination service is reachable. Routing, firewall policy, ports, or the remote application may still be responsible for the connection failure.
A Linux server does not necessarily jump straight from a hostname to an external DNS server. It follows a configured name-resolution path that can include NSS rules, local host information, resolver services, and DNS.
When troubleshooting, separate “Can this system resolve the name?” from “Can it reach the resulting address?” That distinction turns DNS troubleshooting from guesswork into a structured process.
