Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.
How to Troubleshoot DNS Resolution Problems on Ubuntu
Kevin Wu
August 27, 2026· Updated October 4, 2026· 10 min read
When Ubuntu DNS is not working, first prove that the network link and IP path still work, because DNS resolution problems on Ubuntu exist only when that path works but a hostname fails or returns the wrong answer. Then run resolvectl status and resolvectl query to see which DNS server and routing domain the active link actually uses, and record the current owner and values before testing one temporary change. After clearing it, let the configuration owner reapply its settings and compare the result with the saved state.
Key Takeaways
- A Wi-Fi or Ethernet link, an IP route, internet reachability, and DNS resolution are different layers.
- Ubuntu can select DNS per link; the server listed globally may not handle a particular query.［1］
/etc/resolv.confmay be managed by systemd-resolved or another network component. Do not overwrite or unlink it blindly.［2］- A public resolver can be a temporary comparison, not a universal permanent fix.
Start with the general Device and App Troubleshooting Guide if several layers may be failing. The existing DNS server not responding overview explains DNS more broadly; this guide focuses on Ubuntu's current resolver state.
How do you troubleshoot DNS resolution problems on Ubuntu, step by step?
Step 1: Capture the failing state
Save the failing hostname, exact error, time, active interface, and current resolvectl status output before changing anything.
Step 2: Prove the link and route
Confirm that the expected Wi-Fi or Ethernet link is up and that the failing path has a route. If the link or route is absent, remain on that branch instead of changing DNS.
Step 3: Compare IP and name behavior
Compare an authorized IP-level check with a system hostname query. Treat DNS as the leading hypothesis only when the IP path works and name resolution fails or returns the wrong answer.
Step 4: Identify the selected resolver path
Run resolvectl status and resolvectl query for the exact name. Identify the chosen link, server, routing domain, and whether the failure is global or limited to one domain.
Step 5: Find the configuration owner
Inspect /etc/resolv.conf and the active network stack. Record whether NetworkManager, Netplan, DHCP, a VPN, systemd-resolved, or policy supplies the value.
Step 6: Test one temporary per-link value
If the owner and environment permit it, change one per-link DNS value temporarily, repeat the same query, then run resolvectl revert for that link.
Step 7: Let the owner reapply settings
Let the configuration owner reapply its settings and compare the new status with the saved output. Do not describe revert as restoring a saved snapshot.
Step 8: Repair the owning layer and verify
Make a persistent repair only in the owning layer, with a rollback path, then repeat the original query and confirm that internal as well as public names behave as intended.
The result of each step decides the next branch. If both IP and name checks fail, a public resolver comparison cannot prove a DNS-only fault. If only one split-DNS name fails, replacing every resolver can break the routes that still work. If the temporary server succeeds, you have a useful comparison—not permission to leave an unmanaged override behind.
How do you prove the failure is DNS?
Write down the failing hostname, exact error, time, network interface, and whether the same request works on another device or network. Check the link and routes without assuming that a connected icon proves internet access:
ip -brief link
ip route
Then compare an IP-level destination that you are authorized to test with a hostname used by the same service. A successful IP path plus a failed name query supports a DNS hypothesis. If both fail, investigate the router, captive portal, local route, firewall, or upstream connection instead. The router no-internet troubleshooting tree covers network-wide failures.
Avoid using only a cached browser tab as the test. Browsers can use their own encrypted DNS setting, cache, proxy, or secure network feature, so compare a system resolver query as well.
What does resolvectl status show?
Run:
resolvectl status
resolvectl query example.com
Replace example.com with the actual failing hostname when it is safe to disclose locally. Status shows global and per-link DNS servers, search or route-only domains, protocols, and the active interface state. Query reports the returned addresses and usually the link and protocol involved. The resolvectl manual also provides statistics and cache-reset operations, but resetting a cache should follow evidence, not replace diagnosis.
Look for:
- whether the expected Wi-Fi, Ethernet, VPN, or tunnel link is active;
- which link has the default DNS route or the closest matching routing domain;
- whether the DNS server belongs to DHCP, a managed network, a VPN, or a manual setting;
- whether only one domain fails, especially an internal split-DNS name;
- whether the result changes after reconnecting the same link.
Per-link routing means two servers in the output are not necessarily interchangeable. A corporate domain may deliberately go to a VPN link while public names use the home connection.
Who owns the DNS configuration?
Inspect the resolver file rather than editing it:
ls -l /etc/resolv.conf
cat /etc/resolv.conf
systemctl is-active systemd-resolved
The systemd-resolved manual describes several supported /etc/resolv.conf modes, including symlinks to a local stub or generated resolver list, as well as operation with a file managed elsewhere. A generated file can change when DHCP, NetworkManager, Netplan, a VPN, or a management policy updates the link.
Identify the actual owner on this machine. NetworkManager profiles, Netplan configuration, server network tools, and organization policy have different persistent configuration paths. Do not copy a file path from another Ubuntu version and treat it as universal. If the device is managed, ask the administrator before changing DNS or a VPN profile.
How do you run a reversible DNS test?
First save the relevant resolvectl status output and identify the interface name. If systemd-resolved owns the active per-link state, an administrator can temporarily set a test server on that link:
sudo resolvectl dns interface-name resolver-address
resolvectl query example.com
sudo resolvectl revert interface-name
Use actual values appropriate to your network. The revert command removes the temporary override and resets all per-link DNS settings to their defaults; it does not replay a saved configuration. After reverting, let the actual configuration owner reapply its settings, reconnecting only when that is the owner's supported method, and compare resolvectl status with the output saved before the test. Run the same query before, during, and after the change. A success during the test suggests the original server or its route needs investigation; it does not prove that the test server is the correct permanent choice.
Do not change DNS and disable a VPN, proxy, firewall, and IPv6 at the same time. Multiple changes destroy the comparison. Do not permanently hard-code a public resolver on a network that requires internal names, filtering, parental controls, or organization policy.
How do you make a persistent repair?
Repair the layer that owns the value:
- for DHCP-provided DNS, correct the router or DHCP server when all clients receive the bad value;
- for a NetworkManager-managed connection, use that profile's supported setting and reconnect deliberately;
- for a Netplan-managed server, use the schema supported by that Ubuntu release, validate the change, and preserve console access;
- for a VPN or managed device, correct the VPN profile or contact its administrator;
- for one failing authoritative domain, contact the domain or service owner rather than replacing every client resolver.
Record the original configuration and have a rollback path before applying a persistent change. Afterward, reconnect or apply only through the owning tool, then repeat resolvectl status and the original query.
What if DNS fails only during apt update?
Preserve the exact repository hostname and error. If resolvectl query fails for that hostname, remain on the DNS branch. If it resolves but APT reports a signature, release-file, TLS, repository, or dependency error, DNS is not the primary diagnosis. Continue with the guide to APT errors and dependency recovery.
Summary
Prove link and IP reachability before calling a failure DNS. Read global and per-link state with resolvectl, identify which component owns the values, and change one variable only. Clear the temporary override and let the owner reapply its settings; make any persistent repair in NetworkManager, Netplan, DHCP, VPN, or policy—not by blindly replacing /etc/resolv.conf.
FAQ
Why does an IP address work while a hostname fails?
That pattern can indicate name-resolution failure because the IP route works without translating a name. Confirm with resolvectl query and rule out an application-specific proxy or cache.
Why are several DNS servers shown?
Ubuntu can receive servers from multiple links. Routing domains and the default DNS route determine which link handles a query, especially with VPN split DNS.
Should I edit /etc/resolv.conf directly?
Usually not until you know its owner. It may be a managed symlink or generated file, so a direct edit can be overwritten or break the supported resolver mode.
Is restarting systemd-resolved always the fix?
No. A restart may clear temporary state but does not correct a bad DHCP value, failed upstream server, wrong routing domain, or managed VPN policy.
Should I delete the /etc/resolv.conf symlink?
No. First identify its documented mode and configuration owner. Deleting it can disconnect applications from the local stub or generated server list.
Can I permanently use a public DNS server?
Only after considering internal domains, privacy, filtering, policy, and reliability. A short comparison is not enough evidence for a permanent change.
What if DNS is not working on Ubuntu Server?
On Ubuntu Server, Netplan usually owns the persistent DNS values, listed under the interface's nameservers key with addresses and optional search entries. Edit that owning Netplan file, or the cloud-init setting that generated it, instead of /etc/resolv.conf, then apply the change with sudo netplan try: it rolls the change back unless you confirm it within the timeout, 120 seconds by default. Keep console access, confirm that a rejected change was really reverted, and repeat resolvectl status and the original query.
How do I undo a temporary resolvectl dns test?
Run sudo resolvectl revert interface-name for the same link. This clears the temporary override and resets that link's DNS settings to their defaults; it does not restore saved settings. Let the configuration owner reapply its settings, then compare resolvectl status with the output saved before the test.
Does a VPN connection change Ubuntu's resolver selection?
If a name fails only after a VPN connects, compare the selected link, DNS server, and routing domain for that same name before and after connection. A VPN profile may supply per-link DNS or route-only domains, so a failure limited to an internal name can reflect split-DNS routing rather than a broken public resolver. Keep the physical network unchanged and follow the network owner's policy for the comparison.［1］［2］
If AethoVPN is part of the connection being tested, record its connection state alongside resolvectl status and the original query result. That observation is needed to establish whether this setup changes DNS; the brand name alone does not identify the configuration owner. Repair an incorrect DHCP value or persistent NetworkManager/Netplan setting at its source, and confirm internal names still work after clearing any temporary override.
Disclaimer: Resolver ownership and persistent network configuration vary by Ubuntu release, installation type, network stack, VPN, and organization policy. Preserve console access and original settings before changes.
Sources:
- Ubuntu Manpage Repository — resolvectl(1) — https://manpages.ubuntu.com/manpages/noble/man1/resolvectl.1.html
- Ubuntu Manpage Repository — systemd-resolved(8) — https://manpages.ubuntu.com/manpages/noble/man8/systemd-resolved.8.html
Sources checked 4 October 2026.
Related Articles:
