A Linux server can reach an IP address and still fail when an application uses a hostname such as example.com. Before the connection can begin, something has to translate that name into an address the networking stack can use.
DNS is central to that job, but Linux name resolution is broader than “ask a DNS server.” Local files, the Name Service Switch, resolver libraries, and services such as systemd-resolved can all participate. Understanding those layers makes DNS failures much easier to locate.
Linux applications commonly use system resolver interfaces to translate hostnames into IP addresses. The system’s name-service configuration determines which sources can answer. Depending on the machine, those sources may include /etc/hosts, DNS, and local resolver services.
/etc/nsswitch.conf helps define the host lookup policy. /etc/resolv.conf traditionally supplies DNS resolver settings such as name servers and search domains, although modern systems may generate or manage that file through another service.
- Why name resolution must happen before many network connections can begin.
- Why DNS and Linux name resolution are related but not identical.
- What /etc/hosts, /etc/nsswitch.conf, and /etc/resolv.conf do.
- Where a local resolver such as systemd-resolved can fit into the path.
- How A, AAAA, and CNAME records differ.
- How to inspect name resolution safely with getent and resolver tools available on the system.
- 🌐 What Is Linux DNS Name Resolution?
- Name
- Resolver
- Address
- 🧠 The Mental Model: DNS Is One Layer in the Path
- 🗂️ Three Linux Files You Should Recognize
- /etc/nsswitch.conf: Which Source Should Be Used?
- /etc/hosts: Local Name Mappings
- /etc/resolv.conf: Resolver Configuration
- 📡 Where systemd-resolved Fits
- 📚 DNS Records: A, AAAA, and CNAME
- 🔄 What Happens When an Application Resolves a Name?
- The application requests address information
- The local name-service policy is applied
- A local source may answer
- The resolver performs or delegates DNS work
- The application receives address information
- 🔍 Why getent Is Useful
- 🧪 Mini Lab: Trace Your Linux Resolution Setup
- Step 1 — Read the NSS host policy
- Step 2 — Inspect local host mappings
- Step 3 — Inspect resolver configuration
- Step 4 — Ask the system to resolve a hostname
- Step 5 — Check systemd-resolved when applicable
- 🛠️ DNS Failure or Network Failure?
- ⚠️ Common Mistakes
- 💡 A Practical Troubleshooting Order
- ✅ Knowledge Check
- 📚 Official References
🌐 What Is Linux DNS Name Resolution?
Applications are often given names, while IP networking ultimately needs addresses. A browser may receive www.example.com, but before it can create a TCP or UDP-based exchange with the destination, it normally needs suitable address information.
Name resolution is the process of turning a name into information the application can use, commonly one or more IPv4 or IPv6 addresses. DNS, the Domain Name System, is the distributed naming system that provides much of this information.
The distinction matters because Linux can obtain host information from sources other than DNS. A local mapping may answer first, or a resolver service may stand between the application and upstream DNS servers.
Name
The application starts with a human-readable hostname such as www.example.com.
Resolver
The operating system follows its configured resolution path to find suitable address information.
Address
The application receives one or more addresses it can use for the next networking step.
🧠 The Mental Model: DNS Is One Layer in the Path
A useful beginner model is to follow the request from the application outward.
On systems using the GNU C Library Name Service Switch model, the hosts: entry in /etc/nsswitch.conf describes the configured sources used for host lookups and the policy around them.
A simple configuration can look like this:
hosts: files dnsIn this simplified example, files refers to local host information such as /etc/hosts, while dns enables DNS-based lookup through the corresponding NSS mechanism.
Real systems may show additional modules such as resolve, myhostname, or distribution-specific entries. Do not replace the actual configuration with the simple example in your mental model.
When troubleshooting, ask “How did this application try to resolve the name?” before asking only “Is the DNS server working?” The first question includes the complete local resolution path.
🗂️ Three Linux Files You Should Recognize
Three files provide a useful map of traditional Linux host resolution. Their exact role can vary when additional resolver services are installed, but each is worth recognizing.
| File | Main Purpose | Troubleshooting Question |
|---|---|---|
| /etc/nsswitch.conf | Configures name-service sources and lookup policy for several system databases. | Which sources can Linux consult for host information? |
| /etc/hosts | Provides local static mappings between addresses and hostnames. | Is this name being answered locally? |
| /etc/resolv.conf | Traditional resolver configuration containing directives such as nameserver and search. | What DNS resolver information is configured here? |
/etc/nsswitch.conf: Which Source Should Be Used?
The Name Service Switch, or NSS, is not specific to DNS. It provides configuration for several kinds of lookups. For this lesson, the important database is hosts.
Inspect its configuration without changing anything:
grep '^hosts:' /etc/nsswitch.confThe result tells you which NSS services are configured for host lookups. The precise behavior can include status-dependent actions encoded in the NSS configuration, so the order alone is not always the whole policy.
/etc/hosts: Local Name Mappings
/etc/hosts stores local address-to-name mappings. A line can conceptually look like this:
192.0.2.20 app.example.testIf the configured lookup path consults local files and finds a usable entry, an application can obtain an address without needing an ordinary upstream DNS lookup for that name.
This makes /etc/hosts useful for deliberate local mappings, but it can also explain confusing troubleshooting results when an old entry overrides what an administrator expects from DNS.
/etc/resolv.conf: Resolver Configuration
The resolver configuration file traditionally contains information such as DNS name server addresses and search-list settings:
nameserver 192.0.2.53
search example.testThe nameserver directive identifies a name server address available to the resolver. Multiple name server entries may be configured. The search directive supplies a search list that can affect how suitable non-absolute names are tried.
Do not immediately edit /etc/resolv.conf when DNS fails. On many modern Linux systems it is generated or linked to configuration managed by networking software or a resolver service. First identify who owns the configuration.
📡 Where systemd-resolved Fits
Some Linux distributions use systemd-resolved to provide local network name resolution. It can maintain DNS information for individual network links and expose a local resolver interface to applications.
On a system using its local DNS stub listener, /etc/resolv.conf may contain:
nameserver 127.0.0.53This does not mean that 127.0.0.53 is the final authoritative or recursive DNS server somewhere on the network. It is a loopback address used by the local systemd-resolved stub listener. The resolver service can then process and route queries according to its own DNS configuration.
If systemd-resolved is active, the following command can show its current resolver state:
resolvectl statusThe output can include global and per-link DNS configuration. Per-link information matters on systems using multiple interfaces, VPNs, or networks with different DNS settings.
A local stub address is an intermediate destination, not necessarily the end of the DNS path. When a resolver service is involved, inspect the service’s state rather than assuming that /etc/resolv.conf lists every upstream server directly.
📚 DNS Records: A, AAAA, and CNAME
DNS contains different record types because not every question is “What IPv4 address belongs to this name?” Three record types are especially useful when learning host resolution.
| Record | Purpose | Simplified Meaning |
|---|---|---|
| A | Maps a domain name to an IPv4 address. | Name → IPv4 address |
| AAAA | Maps a domain name to an IPv6 address. | Name → IPv6 address |
| CNAME | Identifies the canonical name for an alias. | Alias → canonical domain name |
An application resolving a hostname can ultimately receive IPv4 addresses, IPv6 addresses, or both. The existence of a CNAME can add another DNS name to the resolution chain before address records are reached.
This is also why “the IP for a domain” is often an oversimplification. A hostname may have several address records, and DNS data can change over time according to the zone’s configuration and caching behavior.
🔄 What Happens When an Application Resolves a Name?
The application requests address information
A program commonly uses an operating-system resolver interface such as getaddrinfo() rather than manually reading DNS packets itself.
The local name-service policy is applied
On an NSS-based system, the configured host sources determine which mechanisms can participate in answering the request.
A local source may answer
A matching local host entry or another configured local mechanism can provide the required information before a conventional upstream DNS lookup is necessary.
The resolver performs or delegates DNS work
If DNS is needed, the request follows the resolver configuration. A local service such as systemd-resolved may receive the query first and then contact an appropriate upstream resolver.
The application receives address information
The application can then use a suitable returned address for the next stage of communication. DNS resolution itself does not establish the later TCP, UDP, or other transport exchange.
🔍 Why getent Is Useful
DNS-specific tools are excellent when the question is specifically about DNS. But an administrator often needs to ask a different question first:
What does this Linux system resolve through its configured host lookup path?
On systems providing getent, query the hosts database with:
getent hosts example.comFor address-oriented output using the ahosts database:
getent ahosts example.comgetent works through databases supported by the system’s Name Service Switch libraries. That makes it useful when investigating what normal NSS-based system resolution sees rather than testing only one manually selected DNS server.
Do not expect the IP addresses returned for a public domain to remain identical forever. DNS configuration, address families, load distribution, and other operational choices can legitimately change the answer.
🧪 Mini Lab: Trace Your Linux Resolution Setup
Goal: inspect the local hostname-resolution path without changing configuration.
Step 1 — Read the NSS host policy
grep '^hosts:' /etc/nsswitch.confObserve: identify entries such as files, dns, resolve, or other modules. Your system does not need to match a textbook example.
Step 2 — Inspect local host mappings
cat /etc/hostsObserve: look for loopback names and any administrator-defined mappings. A relevant entry here may explain why a hostname resolves differently from public DNS.
Step 3 — Inspect resolver configuration
cat /etc/resolv.confObserve: note nameserver, search, and options directives if present. Also look for comments or symbolic-link behavior indicating that another component manages the file.
Step 4 — Ask the system to resolve a hostname
getent ahosts example.comObserve: if address information appears, the configured host-resolution path found an answer. The command alone does not prove that the answer required a direct external DNS query.
Step 5 — Check systemd-resolved when applicable
resolvectl statusObserve: if the command and service are available, compare global resolver information with DNS settings attached to individual network links.
Interpretation: you now have four separate pieces of evidence: lookup policy, local mappings, resolver configuration, and the result visible through the system’s name-service path.
🛠️ DNS Failure or Network Failure?
A hostname failure and a connection failure are not the same problem. Separating them prevents unnecessary DNS changes.
| Observation | What It Suggests | Investigate Next |
|---|---|---|
| Hostname does not resolve | The name-resolution path needs investigation. | NSS policy, local mappings, resolver service, DNS configuration. |
| Hostname resolves but connection fails | Resolution produced an address, but a later networking stage failed. | Route, firewall, port, service state, destination reachability. |
| System result differs from expected public DNS | A local source, cache, split DNS, or resolver policy may affect the answer. | Hosts file, NSS, resolver service, network-specific DNS. |
| /etc/resolv.conf shows 127.0.0.53 | systemd-resolved’s local stub may be in the path. | Inspect resolver state with resolvectl when applicable. |
Keep two questions separate: “Can Linux obtain an address for this name?” and “Can the application reach that address?” Solving the first does not guarantee the second.
⚠️ Common Mistakes
DNS is an important source, but Linux can also obtain host information from local files and other configured name-service mechanisms.
The file may be generated by another component. A manual edit can be overwritten and may change the wrong layer of configuration.
A local mapping, resolver cache, or another configured source may have provided the answer.
A hostname can have multiple A or AAAA records, and DNS data can legitimately change over time.
If the system obtains the expected address but the connection still fails, investigate the next layers: routing, firewall policy, transport port, and the destination service.
💡 A Practical Troubleshooting Order
When an application reports a name-resolution problem, collect evidence from the local system before changing configuration.
- Test the hostname through the system lookup path with getent.
- Inspect the hosts: policy in /etc/nsswitch.conf.
- Check /etc/hosts for a local mapping.
- Inspect /etc/resolv.conf and determine whether another component manages it.
- If a resolver service such as systemd-resolved is involved, inspect its current state.
- Once the hostname resolves correctly, move to routes, firewall rules, ports, and service availability if communication still fails.
This sequence keeps the investigation aligned with the actual path: application → local resolution policy → resolver → address → network connection.
✅ Knowledge Check
- Why is Linux name resolution broader than DNS?
- What does the hosts: entry in /etc/nsswitch.conf help control?
- Why can an entry in /etc/hosts change what an application resolves?
- What does 127.0.0.53 commonly represent on a system using systemd-resolved’s stub resolver?
- What is the difference between A, AAAA, and CNAME records?
- If getent returns an address but an application still cannot connect, what should you investigate next?
🎓 Check Your Answers
- Name resolution describes the broader process of obtaining information for a hostname. DNS can provide the answer, but local files and other configured name-service mechanisms may participate as well.
- It defines the configured name-service sources and policy used for host lookups on NSS-based systems. This helps determine whether local files, DNS, resolver modules, or other mechanisms participate.
- If the system’s lookup policy consults local files and finds a matching entry, that local mapping can satisfy the lookup without requiring the expected upstream DNS answer.
- It commonly represents the local DNS stub listener provided by systemd-resolved. The local service can then route the request according to its configured DNS information.
- An A record maps a name to an IPv4 address. An AAAA record maps a name to an IPv6 address. A CNAME identifies a canonical domain name for an alias rather than directly supplying an IP address.
- The successful resolution shows that an address can be obtained, so the investigation should move to later stages such as routing, firewall policy, the destination port, and whether the remote service is actually available.
Do not picture Linux DNS as an application sending every hostname directly to one DNS server. Think of a resolution path: the application asks for address information, the system follows its configured name-service policy, and local sources or DNS can contribute to the answer.
For troubleshooting, remember the boundary: name resolution finds an address; networking then tries to reach it. Keeping those stages separate makes failures much easier to locate.
