iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
If Ubuntu shows Temporary failure resolving 'archive.ubuntu.com' or Could not resolve while running apt-get update, the failure is almost always hostname lookup—not a package dependency problem. First prove whether the machine has a working link and route, then test DNS independently, inspect systemd-resolved and /etc/resolv.conf, and only afterward check APT’s repository sources. Make the permanent change in the system that owns networking (Netplan, DHCP, a network manager, VPN configuration, or systemd-resolved), run a clean update, and leave APT signature checking enabled.
What “Unable to Resolve” means
APT downloads package indexes from repository hostnames. apt update (and its apt-get update equivalent) resynchronizes the local package indexes from the configured sources; an upgrade should come only after that synchronization succeeds.
When output contains Temporary failure resolving 'archive.ubuntu.com', Could not resolve 'security.ubuntu.com', or a similar message, Ubuntu failed to translate the repository hostname into an IP address before it could fetch any index. The likely fault is one of these:
- The interface has no usable address or default route.
- The configured DNS server is unreachable or incorrect.
- The local resolver service is stopped, stale, or receiving bad per-link settings.
- The repository hostname or release source contains a typo, retired mirror, or a DNS zone that your network blocks.
This is different from a dependency conflict, a missing package, or a repository-signature failure. Those occur after APT has reached a server and received repository data.
Recognize the exact failure before changing anything
| Message or symptom | What it tells you | First place to investigate |
|---|---|---|
Temporary failure resolving 'archive.ubuntu.com' |
Hostname lookup failed before the archive could be contacted. | Link, route, DNS configuration, and resolver service. |
Could not resolve 'security.ubuntu.com' |
The security repository name could not be resolved. | DNS and the security source entry; then test another hostname. |
| One mirror fails while unrelated hostnames resolve | The problem may be mirror-specific, a typo, or a blocked DNS zone. | Repository source and mirror choice. |
| APT reaches a server but reports an unsigned or changed Release file | DNS worked; this is a repository trust problem. | Repository identity and signing configuration, not resolver settings. |
Do not treat every APT error as DNS. Capture the complete output so you can see which hostnames fail and whether the error changes between attempts.
Run this diagnostic sequence in order
The commands below move from the lowest networking layer to APT. Stop changing configuration once a test identifies the failing layer; fixing a higher layer cannot repair a broken lower one.
1. Confirm an address and a default route
ip addr
ip routeip addr should show the active interface with an address appropriate for your network. ip route should show a default route, normally a line beginning with default via. If the interface is down, has no address, or lacks a default route, DNS changes will not restore Internet access. Correct the network connection, DHCP, Wi-Fi, virtual-machine adapter, or host networking first.
2. Separate Internet reachability from DNS
Test a known numeric address only when you have a reachable endpoint suitable for your environment. For example:
ping -c 1 1.1.1.1A successful numeric-address test proves that at least one route to that endpoint works without requiring a hostname lookup. It does not prove that every Internet destination is reachable, and some networks block ICMP, so a failed ping is not conclusive by itself. If a numeric test succeeds while hostname tests fail, DNS becomes the leading suspect. If both fail, repair the link, route, firewall, proxy, or upstream connection before editing resolver files.
3. Test name lookup independently of APT
getent hosts archive.ubuntu.com
resolvectl query archive.ubuntu.com
ping -c 1 archive.ubuntu.comYou do not need all three commands to succeed in every environment, but they provide useful cross-checks:
Recommended Free Tools
getent hostsasks the system name-service path used by ordinary applications.resolvectl queryasks the resolver service directly and reports the answer or the lookup failure.pingcombines a hostname lookup with an attempt to send traffic, so distinguish “name could not be resolved” from packet loss.
If a numeric test works but these hostname lookups fail, continue with resolver inspection. If resolvectl query works but APT still reports an unresolved host, check the exact hostname in the APT source and look for a different failing repository.
4. Inspect active DNS servers and links
resolvectl status
systemctl status systemd-resolvedresolvectl status displays global and per-link DNS information, including the upstream servers currently selected for each interface. It also helps reveal whether a VPN or another network service has supplied different DNS settings. The systemd-resolved service normally listens locally on 127.0.0.53. That address is a local stub listener, not the upstream DNS server itself; the upstream addresses appear in the status output.
If the service is inactive or failed, inspect its status output for the immediate cause before restarting it. A service restart can be a diagnostic step, but it is not a substitute for correcting the configuration that keeps supplying bad DNS information.
5. Inspect, but do not blindly overwrite, /etc/resolv.conf
ls -l /etc/resolv.conf
cat /etc/resolv.confOn a systemd-resolved setup, /etc/resolv.conf may be a symbolic link to /run/systemd/resolve/stub-resolv.conf or /run/systemd/resolve/resolv.conf. The link target tells you which generated view is in use. A file that lists 127.0.0.53 is consistent with the local stub arrangement; it does not identify the external DNS servers.
Do not replace a generated file with a hand-edited list as a first resort. DHCP renewals, link changes, reboots, VPN connections, or the resolver service can overwrite it, leaving the symptom to return.
Apply a durable DNS fix in the layer that owns networking
There is no universal DNS address or one command that is correct for every Ubuntu installation. A laptop using DHCP, a server managed by Netplan, and a machine attached to a corporate VPN can legitimately require different resolvers. Use the configuration owner shown by your diagnostics.
Netplan-managed Ubuntu
List the Netplan files and open the file that defines the affected interface:
ls /etc/netplan
sudoedit /etc/netplan/<configuration-file>.yamlIn the interface’s YAML, correct the nameservers addresses supplied by your network. Preserve the existing renderer, indentation, interface name, DHCP settings, routes, and any policy required by your environment. Do not copy a random public resolver into a production network that depends on internal names, split DNS, VPN filtering, or enterprise logging.
Apply the edited configuration using the Netplan command appropriate to your installation, commonly:
sudo netplan applyIf you are working remotely, use a cautious Netplan workflow supported by your release so a bad YAML change does not disconnect the session. Then verify the result:
resolvectl status
resolvectl query archive.ubuntu.comsystemd-resolved global settings
When systemd-resolved itself owns the resolver policy, use a drop-in rather than editing generated output:
sudo mkdir -p /etc/systemd/resolved.conf.d
sudoedit /etc/systemd/resolved.conf.d/ubuntu-dns.confPut a [Resolve] section and a DNS= line in that file, using DNS servers approved for your network:
Free tools Windows power users keep installed
One-click scans. No signup required.
[Resolve]
DNS=192.0.2.53 192.0.2.54The addresses above are documentation examples, not universal production resolvers. Replace them with reachable, authorized servers for your site, or omit a global override when per-link DHCP or VPN DNS is intentional.
Restart the service and check the active state:
sudo systemctl restart systemd-resolved
resolvectl status
resolvectl query archive.ubuntu.comIf the query still fails, the status output should show whether the configured servers are reachable and whether another link-specific policy is taking precedence.
DHCP, a network manager, or a VPN supplies DNS
If resolvectl status shows DNS servers arriving from DHCP, a network manager, or a VPN, change the setting in that system. A local drop-in may appear to work until the next lease renewal or VPN connection and can interfere with split-DNS rules. Ask the network administrator for the intended resolver addresses and search domains when internal hostnames are required.
Flush stale state only after configuration is correct
A stale cache can be a useful diagnostic possibility when the resolver service is otherwise healthy:
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallsudo resolvectl flush-cachesThis command is supported on relevant systemd-resolved versions. Follow it with a fresh query and inspect the result with resolvectl status. Flushing a cache cannot repair an unreachable upstream server or a malformed source entry.
Check APT sources, hostnames, and release codename
Once ordinary hostname lookups work, inspect what APT is actually trying to contact. Ubuntu 24.04 LTS and later commonly use deb822 sources in /etc/apt/sources.list.d/ubuntu.sources. Older releases commonly use /etc/apt/sources.list, with additional files possible under /etc/apt/sources.list.d/.
grep -R --line-number --no-filename
-E '^(Types:|URIs:|Suites:|Components:|deb )'
/etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/nullCheck each repository hostname character by character. The standard Ubuntu archive and security hosts are archive.ubuntu.com and security.ubuntu.com, although an organization may intentionally use an internal mirror. A mistyped name, a retired mirror, or a DNS zone blocked by policy can produce the same APT wording as a general DNS outage.
Confirm that the source’s release suite matches the installed Ubuntu release:
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →. /etc/os-release
echo "$VERSION_CODENAME"Compare that codename with the Suites: field in a deb822 file or the distribution field in a traditional deb line. Do not change a release suite casually; an incorrect codename can create a different, potentially serious package-management problem even after DNS is repaired.
When only one mirror fails
If unrelated hostnames resolve and only one repository name fails, temporarily selecting the official global archive or another trusted mirror can isolate a mirror-specific problem. Make the change in the source file that owns the entry, run an update, and then decide whether the original mirror needs repair.
Best Value
An /etc/hosts mapping for a known-good mirror address has been used as an emergency workaround, but it should not become the permanent solution. Mirror addresses can change, and a stale mapping can silently send package traffic to the wrong destination. Remove the temporary entry after correcting the source or mirror DNS.
Why the browser may still work when apt-get fails
A browser test does not necessarily exercise the same hostname, repository, interface, or resolver path as APT. You may be visiting a site whose name resolves while archive.ubuntu.com does not, or a browser may be using a different network context. Test the exact APT hostname with getent and resolvectl query rather than treating a working web page as proof that repository DNS is healthy.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Similarly, a successful numeric-address test proves only that a route to that endpoint exists. It does not establish that the configured DNS servers answer queries or that every repository domain is permitted by local policy.
Verify the repair safely
After correcting the network or source configuration, run the update again:
sudo apt-get updateA successful run should fetch or confirm each configured repository without Temporary failure resolving, Could not resolve, or repeated connection errors. Read the entire output: one successful archive does not hide a failure from a second source.
Only after the update completes cleanly should you upgrade or install packages:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemssudo apt-get upgrade
sudo apt-get install package-nameThe update-first order refreshes the local indexes that those later operations depend on.
Do not bypass APT security for a DNS problem
DNS failure happens before APT retrieves repository metadata. An unsigned repository or a changed Release file is a separate trust failure. APT verifies Release-file signatures and rejects unsigned or unauthenticated repositories by default.
Never use --allow-unauthenticated, Trusted=yes, or other insecure-repository overrides to make a resolver error disappear. Restore DNS and correct the repository identity while keeping signature verification enabled. If a clean DNS repair is followed by a signature warning, investigate that warning as a new problem rather than weakening verification.
Quick Recap
Troubleshooting branches by symptom
| Observed result | Likely cause | Next action |
|---|---|---|
No interface address or no default route |
Link, DHCP, virtual adapter, or upstream network failure. | Repair connectivity first; DNS edits cannot create a route. |
| Numeric endpoint reachable; all hostname queries fail | Bad, unreachable, or stale DNS configuration. | Inspect resolvectl status, the resolver service, and the owning Netplan/DHCP/VPN settings. |
resolvectl query works; one APT hostname fails |
Typo, retired mirror, blocked zone, or source-specific issue. | Inspect the exact source entry and test another trusted mirror. |
/etc/resolv.conf was edited, then the error returned |
A generated file was overwritten by a reboot, link change, DHCP, or VPN. | Revert the ad hoc edit and configure the owning network layer. |
| DNS queries work; APT reports a Release-file or signature error | Repository authentication or content trust issue, not name resolution. | Validate the repository and signing configuration; do not disable apt-secure. |
Prevent recurring “Unable to Resolve” failures
- Keep DNS settings in Netplan, DHCP, the network manager, VPN policy, or a systemd-resolved drop-in—the component that will reapply them after reboot and link changes.
- When a VPN is required for internal mirrors, verify both the VPN’s per-link DNS and the route to the mirror.
- Review repository hostnames and release suites after an Ubuntu release change or mirror migration.
- Use
resolvectl statusandresolvectl queryas the first checks when APT suddenly cannot resolve a name. - Run
apt-get updatesuccessfully before upgrades, and treat any later signature warning independently from DNS troubleshooting.
Quick recovery checklist
- Copy the exact APT error and identify every hostname named in it.
- Run
ip addrandip route; restore the interface address or default route if missing. - Test a suitable numeric endpoint, then run
getent hostsandresolvectl queryfor the failing repository host. - Inspect
resolvectl status,systemctl status systemd-resolved, and the/etc/resolv.confsymlink. - Correct DNS in the owning configuration layer; flush caches or restart the resolver only as supporting diagnostics.
- Check the repository hostname and release codename in the active APT source files.
- Run
sudo apt-get update; proceed to upgrades only after all configured sources complete without resolution or connection errors.
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.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →
