Linux server DNS resolution not working can stop package updates, API calls, monitoring, backups, and applications that depend on hostnames. The cause may sit in resolver configuration, network access, a local cache, or one application’s settings. A careful test sequence helps you find the failing layer without changing several variables at once.
Start by defining the DNS failure
First, record what fails and where. A server may resolve a public name but fail to resolve an internal name. It may also resolve names from a shell while a service reports an error. Those differences matter. When Linux server DNS resolution not working affects only one program, avoid assuming the whole host has the same fault.
- Note the exact hostname that fails.
- Record whether the name is public, private, or part of a search domain.
- Check whether the failure affects one server, one application, or several systems.
- Capture the error message and approximate start time.
- Avoid restarting services before collecting basic evidence.
DNS means Domain Name System. It translates names such as updates.example.net into addresses that software can use. A resolver is the client-side component that asks a DNS server, often called a nameserver, for that answer. For a concise overview of nameservers and resolution, see Cloudflare’s DNS overview.
Inspect the resolver configuration
On many Linux systems, applications consult /etc/resolv.conf directly or through a resolver service. Inspect the file first:
cat /etc/resolv.conf
ls -l /etc/resolv.confLook for nameserver lines, a search line, and unexpected options. A nameserver address must be reachable from this server. The file may be a symbolic link managed by NetworkManager, systemd-resolved, or another network tool. Therefore, editing it manually may only provide a temporary result.
Check the active resolver service when present:
resolvectl status
resolvectl dnsSome distributions use a different command or do not run systemd-resolved. If resolvectl is unavailable, inspect the network manager, DHCP lease, or cloud-init configuration that creates the resolver settings.
A useful comparison is the server’s configured nameserver against the expected network design. A business server might need an internal DNS resolver for private hostnames. Replacing it with a public resolver could make public lookups work while breaking internal services.
Check search domains and fully qualified names
A search domain lets a short name expand automatically. For example, a request for fileserver might become fileserver.office.example. The resolver tries combinations from the configured search list.
Search behavior can create confusing results. A short name may resolve to the wrong host, create delays while several suffixes are tried, or fail because the expected suffix is missing. Test both forms:
getent hosts fileserver
getent hosts fileserver.office.exampleUse the fully qualified domain name, or FQDN, when testing a known target. An FQDN contains the complete hostname and domain. In scripts and service configuration, it often removes ambiguity.
Also inspect the effective search settings:
resolvectl status | sed -n '/DNS Servers/,$p'The exact output varies by distribution. Confirm the search suffix with the system administrator or network documentation before changing it. A wrong suffix can affect databases, storage systems, monitoring targets, and internal APIs.
Test nameserver reachability separately
Before blaming DNS records, verify that the server can reach its configured resolver. DNS normally uses UDP port 53, but some queries may use TCP. A firewall, route, security group, or local policy can block one or both. This distinction is central when Linux server DNS resolution not working appears after a network or firewall change.
Start with the route and address:
ip route
ip addr
ping -c 3 <nameserver-address>Ping is only a clue. Many DNS servers do not answer ICMP, so a failed ping does not prove that DNS is unavailable. Test the resolver with a DNS-aware tool instead:
dig example.com @<nameserver-address>
# or, if dig is unavailable:
nslookup example.com <nameserver-address>Replace the example name and address with values approved for your environment. The command should show whether the request timed out, was refused, or returned an answer. A timeout suggests a path, firewall, service, or reachability problem. A response with an error code may point to policy or record behavior.
Compare the configured resolver with a known working system on the same network. Do not assume a public resolver is an acceptable replacement. Internal names, split DNS, and security controls may require the organization’s resolver.
Compare libc behavior with direct DNS queries
Different tools do not always use DNS in the same way. The getent command tests the system’s name service configuration, including the order in /etc/nsswitch.conf. The dig command sends a DNS query directly and usually bypasses that name service order.
grep '^hosts:' /etc/nsswitch.conf
getent hosts example.com
dig example.comWhen dig succeeds but getent fails, inspect /etc/nsswitch.conf, resolver libraries, and local service integration. When both fail, focus on resolver configuration or network reachability. This comparison often narrows Linux server DNS resolution not working to either the host resolver path or the upstream query.
For servers using IPv6, test address families separately:
dig A example.com
dig AAAA example.comAn application may prefer IPv6 and then encounter a routing problem. That does not necessarily mean DNS failed. The returned record type and the application’s connection behavior must be considered together.
Investigate local caching and resolver services
Linux hosts may use a local caching service such as systemd-resolved, dnsmasq, or another resolver daemon. The application may query a loopback address, such as 127.0.0.53, rather than the upstream nameserver directly.
Check listening sockets and relevant services:
ss -luntp | grep ':53'
systemctl status systemd-resolved
journalctl -u systemd-resolved --since "30 minutes ago"Do not run every command on every system. A service may not exist, and service names differ by distribution. The ss reference explains how to inspect sockets. For systemd-managed services, the systemctl manual provides command details.
A stale or corrupted cache can preserve an old answer until its time-to-live expires. A cache flush may help, but it should follow evidence. Record the current state first, then use the documented command for the resolver in use. Avoid deleting resolver files or stopping DNS services without a recovery plan.
Check logs for timeouts, upstream failures, permission errors, and interface changes. Correlate those messages with the start time. A resolver log that shows successful replies shifts attention toward the application or its network path.
Check application-specific DNS behavior
When shell commands work but an application fails, the application may not use the system resolver. Containers, language runtimes, proxies, VPN clients, and security agents can supply separate DNS behavior. That is why Linux server DNS resolution not working may require testing inside the affected service rather than only from an interactive shell.
Compare the service environment
Inspect the service definition and environment:
systemctl cat your-service.service
systemctl show your-service.service --property=Environment
systemctl show your-service.service --property=RootDirectoryLook for a container namespace, custom configuration file, proxy setting, or explicit resolver address. A service running in a container may have a different /etc/resolv.conf and network namespace from the host.
Test from the same execution context whenever possible. A command run as your login user does not prove that a restricted service can resolve the same name. Check permissions, sandboxing, and outbound network rules without weakening them as a quick experiment.
Review application errors and libraries
Applications may report “host not found,” “temporary failure,” connection timeout, or certificate errors. These messages describe different stages. A certificate error can occur after DNS worked and the application reached a server.
Review the application log and configuration. Confirm the hostname, proxy, port, and address family. Some software caches DNS results internally, while other software resolves only at startup. A controlled service restart may be appropriate after correcting configuration, but document the change and confirm the service’s restart policy first.
Use a safe diagnostic sequence
For a repeatable investigation, work from the local system outward:
- Test the exact hostname with
getent. - Inspect
/etc/resolv.confand the effective resolver status. - Check search domains using both short and fully qualified names.
- Query the configured nameserver with
digornslookup. - Verify routes and allowed DNS traffic.
- Inspect local resolver sockets, service status, and logs.
- Repeat tests from the affected application, container, or user context.
- Record the evidence before changing configuration.
Keep a small test table with the hostname, command, resolver address, result, and timestamp. This prevents repeated checks from obscuring the pattern. It also helps a second technician continue the investigation.
When to involve upstream DNS or server support
If direct queries reach the resolver but return incorrect or missing data, inspect authoritative DNS and delegation. That work differs from a local resolver failure. Our guide on finding conflicting DNS records covers comparison of authoritative answers. For broader Linux assistance, see Linux server support from Tech Rescue Ops LLC.
Professional remote assistance may be appropriate when DNS affects production services, several systems fail together, or the resolver is tied to a firewall, VPN, directory, or cloud network. Tech Rescue Ops LLC can help collect evidence, preserve access, and make controlled changes with a rollback plan.