If a Linux machine can ping an IP address but reports unknown host for the corresponding name, network routing is probably working and hostname resolution is failing. Check the name, NSS configuration, resolver service, and DNS servers in that order; then repair the component that owns the active resolver configuration.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What the error tells you
A command such as ping 203.0.113.20 sends packets directly to an address. It does not need to translate a hostname first. A command such as ping server.example.net must first ask Linux’s name-service stack for an address. If the address works but the name produces ping: server.example.net: Name or service not known or unknown host, the two tests have exercised different parts of the system.
As an Amazon Associate I earn from qualifying purchases.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsThat result usually means the interface, route, and remote host are reachable, while hostname lookup is failing locally or at the configured DNS service. SUSE’s administration guidance summarizes the diagnosis: when ping reports unknown host, “the name service is not configured correctly or the host name used was incorrect.” A typo, missing search domain, broken DNS server, incorrect NSS order, stale cache, or special handling for .local names can all produce the same symptom.
Do not infer that the remote server is down from the hostname failure. First establish whether Linux can resolve the exact name, and make every test through the lookup path used by normal applications.
Run the shortest useful diagnostic sequence
-
Verify the name and test NSS with
getentCheck spelling, capitalization where relevant, trailing dots, and the intended domain. Then run:
getent hosts NAMEReplace
NAMEwith the same fully qualified or short name used by the failing application.getentconsults the Name Service Switch (NSS), which is the path used by most Linux programs. If it prints an address and name, the system resolver can answer; a failure here means continue with local configuration and resolver diagnostics.What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Compare independent lookup commands
Use one or both of these commands:
host NAME resolvectl query NAMEhostasks DNS directly through the resolver settings it can access.resolvectl queryasks systemd-resolved when that service is active and can show which link or DNS scope handled the request. A successfulhostresult paired with a failedgetentresult points toward NSS ordering, a local cache, or application-specific policy rather than basic DNS reachability. -
Inspect the active resolver settings
Display the traditional resolver file:
cat /etc/resolv.confLook for one or more valid
nameserverlines and any requiredsearchdomains. SUSE describes this file as tracking the nameserver and domain currently used by the host. An empty file, an unreachable private address, or a search list from an old network can explain why a short name fails while its fully qualified form works. -
Check NSS lookup order
Inspect the hosts rule:
grep '^[[:space:]]*hosts:' /etc/nsswitch.confA common baseline is:
hosts: files dnsThe
hosts:line tells glibc where to look and in what order: usually/etc/hostsfirst, then DNS. Extra modules such asmdns4_minimal,resolve, or a caching daemon change both the order and the conditions under which lookup stops. -
Identify whether systemd-resolved owns the path
On systems that use systemd-resolved, run:
systemctl status systemd-resolved resolvectl status ls -l /etc/resolv.confThe status output shows global and per-interface DNS servers, search domains, DNS scopes, and whether links are configured. The symbolic link reveals whether
/etc/resolv.confpoints to a systemd-resolved stub or another generated file. The link and the running service must agree with the distribution’s resolver design; otherwise applications may read a file that is empty, stale, or unrelated to the active service.Recommended Free Tools
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Ask a DNS server directly
If the
digutility is installed, test a named server:dig NAME @SERVERFor example, use the address shown in
/etc/resolv.conforresolvectl statusinstead of guessing. A timeout indicates that the server is unreachable, blocked, or not answering. A valid DNS answer whilegetent hosts NAMEfails narrows the problem to NSS, a local cache, split-DNS policy, or application behavior.
Understand which resolver design you are debugging
Linux installations do not all obtain DNS information the same way. Before editing anything, determine who owns resolver state and which component will overwrite a manual change.
| Question | What to examine | Why it matters |
|---|---|---|
| Who owns configuration? | NetworkManager, DHCP client, systemd-resolved, another resolver manager, or a static setup | A hand-edited file may be replaced when a lease renews, the network restarts, or the machine reboots. |
| Which servers are active? | /etc/resolv.conf, resolvectl status, NetworkManager connection settings |
The listed address may be unreachable, outdated, or valid only on another network. |
| What is the NSS order? | The hosts: line in /etc/nsswitch.conf |
An early module can return an error that prevents DNS from being attempted. |
| What kind of name is it? | Ordinary DNS, split DNS, internal search-domain name, or .local mDNS |
Different name types use different servers and lookup modules. |
| Which path fails? | Compare getent, host, resolvectl, and the application |
A failure in one path does not prove that every resolver path is broken. |
Repair DNS servers and generated resolver files
Restore the source of DNS settings
If /etc/resolv.conf contains no usable server, restore DNS through the service that supplies it. On a desktop or server managed by NetworkManager, edit the relevant connection profile or renew DHCP rather than repeatedly editing the generated file. On a systemd-resolved design, configure DNS with the network manager or resolved’s per-link settings and ensure the expected /etc/resolv.conf symlink is present.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →A systemd incident documented the characteristic pattern: IP pings succeeded, hostname pings failed, and adding nameserver 8.8.8.8 to /etc/resolv.conf made hostname queries work. That address is an example of a reachable public resolver in that incident, not a universal or permanent fix. Public DNS cannot resolve private corporate zones, may be blocked by a network policy, and may violate an organization’s requirements. Prefer the DNS servers supplied by the current network, VPN, or administrator.
Check reachability of each nameserver
For every configured server, test the DNS service rather than only pinging the server:
Rank #4
dig example.com @192.0.2.53UDP or TCP port 53 may be filtered even when the server responds to ICMP. A timeout from every configured server suggests a network, firewall, VPN, or server outage. A response containing an address proves that server can answer that query, but it does not prove it has the internal zones your application needs.
Account for split DNS
VPNs and modern network managers can assign one DNS scope to a physical interface and another to a tunnel. A public name may resolve through the ordinary interface while an internal name requires the VPN scope. Use resolvectl status to see link-specific servers and search domains. If the internal name is sent to a public resolver, correct the VPN or connection profile instead of adding arbitrary servers globally.
Fix NSS and hosts-file failures
Correct a broken hosts: line
Keep the configuration appropriate for the installed modules. The simple hosts: files dns rule checks local entries and then DNS. If the line names a module that is not installed, or places a failing cache before DNS, lookups can stop prematurely. Red Hat documents failures in which NSS and caching behavior prevent DNS from being attempted.
Pay particular attention to return actions such as [NOTFOUND=return]. That instruction means “stop here when this module reports not found.” It is useful when deliberately enforcing a lookup policy, but it can make a missing local or mDNS entry appear to be a DNS failure. Remove or reposition such an action only when you understand the module’s purpose and the policy required by the machine.
Best Value
Inspect /etc/hosts
Read the local file:
cat /etc/hostsAn incorrect line can send a name to the wrong address, while a missing line can explain why an expected private hostname is unavailable when DNS is intentionally not used. Correct stale mappings, duplicate entries, and accidental typos. Do not add a permanent address merely to hide a DNS outage if the service’s address is expected to change.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Handle .local and multicast DNS names
Names ending in .local are commonly resolved with multicast DNS (mDNS), not ordinary unicast DNS. The NSS line may contain an entry such as:
mdns4_minimal [NOTFOUND=return] ...That rule can deliberately stop processing when the mDNS module does not find a name. Micro Focus has documented cases where ping reports unknown host even though host or nslookup resolves the same name through DNS. The difference occurs because those commands and ping may use different lookup paths.
Decide whether the name is supposed to be mDNS or DNS. For a genuine local-network device, verify that the mDNS service is running, the interface permits multicast traffic, and the name is spelled with the intended .local suffix. For an organization that uses .local as an ordinary DNS zone, coordinate the NSS and resolver configuration so DNS is reached instead of being stopped by an mDNS return rule. Renaming the zone is often the cleaner long-term design, but it may not be immediately practical.
Use the results to isolate the failing layer
| Observation | Most likely area | Next action |
|---|---|---|
getent, host, and resolvectl all fail |
Nameserver, route to DNS, resolver service, or wrong name | Check spelling, resolv.conf, service status, per-link DNS, and direct dig. |
host NAME succeeds but getent hosts NAME fails |
NSS order, cache, local policy, or hosts-file interaction | Inspect /etc/nsswitch.conf, return actions, and /etc/hosts. |
resolvectl query succeeds but applications fail |
Application-specific resolver behavior or an incorrect /etc/resolv.conf path |
Check the application’s configuration and the file it actually reads. |
| Fully qualified name works but short name fails | Missing or incorrect search domain |
Restore the search domain from DHCP, VPN, or the intended network profile. |
Only .local names fail |
mDNS service, multicast filtering, or NSS return rule | Test mDNS and review the mdns modules and their ordering. |
DNS answers are correct but ping still fails |
Address-family choice, firewall, route, or ICMP filtering | Compare the returned IPv4/IPv6 addresses and test the selected address separately. |
Make the fix persistent and verify it
- Record the current state before changing it: save the output of
cat /etc/resolv.conf,grep '^[[:space:]]*hosts:' /etc/nsswitch.conf, andresolvectl statuswhen available. - Change DNS servers, search domains, or NSS settings in the owning network or resolver service. Avoid treating a generated file as the configuration source.
- Restart or reload only the affected service according to the distribution’s design. A network restart may interrupt active sessions, so use a maintenance window on remote systems.
- Repeat
getent hosts NAME, then comparehost NAMEorresolvectl query NAME. Confirm that the returned address belongs to the intended network and zone. - Test the application that originally failed. If it caches DNS, restart that application or wait for its documented cache lifetime.
- Reboot or renew the network lease only when necessary, then verify that the resolver file, symlink, nameservers, and search domains remain correct.
Common mistakes that prolong the outage
- Testing only with ping: Ping combines name lookup with ICMP. Use
getent,host,resolvectl, anddigto separate those functions. - Editing
/etc/resolv.confpermanently: DHCP, NetworkManager, or systemd-resolved may overwrite the edit at reboot, lease renewal, or network restart. - Assuming any public resolver is suitable: It may not know private zones and may be unreachable or disallowed on the network.
- Ignoring the search list: A short name depends on the correct domain suffix. Test the fully qualified name to distinguish this from a general outage.
- Changing NSS blindly: Removing modules can break local files, mDNS, LDAP, or security policy. Change the specific order or return rule that explains the observed failure.
- Confusing DNS success with connectivity: A valid address from
digdoes not guarantee a route, service listener, or permission to receive ICMP.
When to involve the network or system administrator
Escalate with evidence rather than only the original error. Provide the exact name, whether its fully qualified form was tested, the output of getent, host or resolvectl, the active nameservers, the hosts: line, and whether the name is internal, split-DNS, or .local. Include timestamps and whether the failure affects every application or only one. This lets an administrator distinguish a bad local configuration from a DNS-zone outage, VPN scope problem, firewall rule, or remote service issue.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
