Dedicated server DNS failures: trace the resolver path

When a service process reports a name resolution failure but direct access by address still works, immediately changing DNS servers can obscure the original fault. The problem may lie in the application cache, the NSS lookup order, the system resolver service, or an error returned by an upstream server. The goal is not to make an occasional command succeed, but to establish which resolution path the service process actually uses and where that path fails.

This article uses Ubuntu Server 24.04 LTS. After paying for an AMDSSH dedicated server, view the credentials in the console and connect over SSH. If the machine has multiple addresses, use the first one. The checks below do not change interface addresses, routes, or firewall settings, making them suitable for gathering evidence before making changes.

1. Fix the query target and capture the original error

First, save the application error, the queried name, the record type, and the time of the failure. Also establish whether all domain names fail or only one, and whether the affected process runs on the host or inside a container. Short names are affected by search domains, so use a fully qualified domain name with a trailing dot when troubleshooting.

The examples below use amdssh.com. to demonstrate the query format, without assuming that it must return a particular address. For final validation, replace it with a name required by the service and confirmed to have the relevant records. Check the tools first, then capture the basic environment:

command -v getent resolvectl dig
date -Is
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
grep '^hosts:' /etc/nsswitch.conf
systemctl is-active systemd-resolved
resolvectl status

dig is provided by the dnsutils package. If it is not installed, obtain the tools through the repositories already configured on the system. When name resolution is already failing, an installation failure is not fresh evidence of the root cause.

Being able to reach an address does not mean the DNS query path is working. Receiving a DNS response does not mean the application received the record it needs, either. Check the response status, record type, and actual returned data together.

2. Compare NSS with the system resolver service

The three queries are not equivalent

getent queries through NSS and is closer to common system address-resolution calls. resolvectl queries systemd-resolved. dig performs a DNS query and cannot validate the complete NSS path.

getent ahostsv4 amdssh.com.
resolvectl query --type=A amdssh.com.
dig amdssh.com. A +time=2 +tries=1

Read the three results together. If getent returns an old address while the DNS query returns a new one, first check /etc/hosts and the module order on the hosts: line. If resolvectl succeeds but getent fails, check whether the NSS modules are present, whether their order is appropriate, and whether the service runs in a different filesystem environment.

/etc/resolv.conf may point to a local resolver entry point rather than listing the final upstream servers directly. It may also be generated by a network management tool. A local address alone is not evidence of a configuration error. Do not overwrite the symbolic link and then use the result to decide whether the fault has disappeared.

Some applications use their own DNS libraries and bypass NSS. A successful getent lookup therefore confirms that the system path works, not that every application has recovered.

3. Query the upstream directly and separate response errors from transport failures

From resolvectl status, record the DNS servers, routing domains, and current server for the interface used by the failing query. On machines with multiple interfaces, the domain name may determine which upstream is selected; do not simply take the first entry in the output. The commands below prompt for the address of the upstream actually in use, without introducing an unverified public resolver.

read -r -p 'DNS server address: ' DNS_SERVER
dig @"$DNS_SERVER" amdssh.com. A +time=2 +tries=1
dig @"$DNS_SERVER" amdssh.com. A +tcp +time=2 +tries=1
dig @"$DNS_SERVER" amdssh.com. AAAA +time=2 +tries=1

The two-second timeout and single attempt are diagnostic settings, not recommended application timeouts. Keep the complete output, focusing on status, the answer section, query time, and the server actually queried. Do not rely on the command's exit code alone to decide whether the required record is valid.

Act on the response status

NXDOMAIN means the name does not exist. First check its spelling, search domains, and authoritative records. NOERROR with an empty answer section may simply mean that no record of that type exists; it should not be treated as a network failure. SERVFAIL indicates a failure during resolution and requires further investigation using upstream logs or assistance from the upstream administrator. For REFUSED, check whether the query is permitted.

If UDP queries time out while TCP queries succeed, the two transport paths are behaving differently; investigate the relevant network policies next. If both time out, check the route and access policies to that upstream, but do not infer from a timeout alone that the server is down. If the upstream responds but the system path fails, return to local configuration and caches.

4. Repair based on evidence without bypassing the configuration owner

First determine which layer manages the DNS configuration. Ubuntu Server may use Netplan to pass configuration to a specific network backend, or it may use another management method. Persistent changes belong in the configuration files of the component that actually manages the settings, not just in the generated /etc/resolv.conf.

If you have confirmed that the authoritative records have been corrected but systemd-resolved still holds an old result, capture the evidence before clearing its cache:

resolvectl statistics
sudo resolvectl flush-caches
resolvectl query --type=A amdssh.com.
getent ahostsv4 amdssh.com.

Flushing the cache does not change the upstream or clear an application's own cache. If the name previously returned a nonexistence response, negative caching may also be involved. Use the SOA information in the response to assess it; repeated service restarts are not a repair strategy.

Before changing the NSS order, save the original file and identify which modules handle local files, DNS, or other name sources. Modules with conditional actions can terminate the lookup early, so checking for the word dns alone is not enough.

If a persistent DNS configuration change is genuinely needed, save the configuration, check its syntax, and prepare steps to restore the original file. Before applying network changes remotely, keep the existing SSH session open and prefer a reversible apply mechanism provided by the configuration management tool. Do not change DNS, routes, and interface names at the same time.

5. Validate in the service process environment

After the host recovers, check the resolver files visible to containers or isolated services. A container may have its own /etc/resolv.conf, and a process may still cache old addresses. Repeat the queries inside the actual runtime environment rather than only running the same command in the host terminal.

Final validation includes these checks:

• Query each required record type for the service's fully qualified domain name, and verify that the addresses match their intended use.
• Compare the results from NSS, the system resolver service, and the upstream actually in use.
• Make a real service request to distinguish a name resolution failure from a subsequent connection failure.
• Check whether the application is pinned to an old address and whether its cache needs to be refreshed through its management interface.
• Confirm that the correct configuration owner has saved the settings persistently; check after a controlled reboot that they have not been overwritten.
• Retain the before-and-after output, configuration differences, and service request results rather than recording only “recovered.”

If the problem affects only one process, continue investigating its resolver, runtime environment, and connection pool instead of broadening the changes to the entire machine's network configuration. A complete investigation should explain the original error, identify the failing layer, and demonstrate that service requests follow the expected resolution path after the repair.

Frequently asked questions