The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →“Temporary failure resolving ‘archive.ubuntu.com’” means Ubuntu could not translate the repository hostname into an IP address. The failure happens before APT downloads package indexes, so changing package dependencies or disabling signature checks will not fix it. Check the network route, test DNS independently, repair the resolver configuration that owns the machine, then run sudo apt update before upgrading.
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 “Unable to Resolve” Means
APT retrieves package indexes from repository hostnames. The apt update operation resynchronizes those local indexes with the configured sources; an upgrade should come only after that update succeeds. When APT prints Temporary failure resolving 'archive.ubuntu.com', Could not resolve, or a similar message, hostname lookup failed before APT could fetch repository metadata.
As an Amazon Associate I earn from qualifying purchases.
The likely fault is the network path, DNS service, resolver configuration, or repository hostname—not a package dependency conflict. The same diagnosis applies when the message names security.ubuntu.com or an organization’s internal mirror.
How this differs from other APT failures
| Message pattern | What it indicates | First place to investigate |
|---|---|---|
Temporary failure resolving or Could not resolve |
The hostname could not be translated to an address. | Interface, route, DNS servers, resolver service, or source hostname. |
| Connection timed out or connection refused | A name may have resolved, but the connection to the repository did not complete. | Firewall, proxy, routing, mirror availability, or network policy. |
Unsigned or changed Release file |
APT received repository metadata but rejected its trust information. | Repository signing and source configuration, not DNS. |
Use This Diagnostic Order
Run the checks in sequence. Each result narrows the fault without making a potentially destructive configuration change.
1. Confirm the interface has an address and a route
ip addr
ip routeLook for an address on the interface that should carry traffic and a default route in the routing table. A missing address or default route is a network-connection problem, so repair the wired, wireless, virtual-machine, container, or VPN connection before changing DNS.
To separate Internet reachability from name resolution, test a suitable reachable numeric address available in your environment. A numeric-address test does not require DNS. If the numeric test fails, DNS is not yet the only problem; restore the route or upstream connection first. If it succeeds while hostname tests fail, DNS becomes the leading cause.
Free tools Windows power users keep installed
One-click scans. No signup required.
2. Test the repository name without APT
getent hosts archive.ubuntu.com
resolvectl query archive.ubuntu.com
ping -c 1 archive.ubuntu.comgetent tests the system name-service path used by applications. resolvectl query asks the systemd-resolved resolver directly and shows whether it can obtain an answer. A single ping can also expose lookup failure, although a host may resolve while blocking ICMP, so a failed ping alone is not proof that DNS is broken.
Run at least one hostname test and compare it with the numeric-address test. A working numeric connection plus failing getent or resolvectl is strong evidence of a DNS or resolver problem.
3. Inspect active DNS servers and links
resolvectl statusThis displays global and per-link DNS information, search domains, and the interfaces that supplied those settings. Pay attention to the link carrying your default route. A VPN or enterprise network can intentionally provide per-link or split-DNS settings; replacing them with unrelated public servers can make internal names, authentication, or security controls fail.
4. Check the resolver service
systemctl status systemd-resolved
resolvectl statusOn a normal systemd-resolved setup, the local stub listener is commonly 127.0.0.53. That address is the local resolver endpoint on the Ubuntu machine, not the upstream DNS server. Upstream servers can come from global systemd-resolved configuration, per-link settings, DHCP, Netplan, a network manager, or a VPN.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →If the service is stopped or failed, record the status output and repair the service or the network component that owns it. If it is running, continue by checking its effective upstream servers rather than assuming that a running process guarantees usable DNS.
5. Inspect /etc/resolv.conf without overwriting it
ls -l /etc/resolv.conf
cat /etc/resolv.confUbuntu systems using systemd-resolved may link this path to /run/systemd/resolve/stub-resolv.conf or /run/systemd/resolve/resolv.conf. The link target indicates whether applications are pointed at the local stub or at a generated list of upstream servers. A hand-edited file can appear to fix one session and then be replaced at reboot or when a network link changes.
Do not delete the link or replace the file blindly. First determine whether Netplan, DHCP, a network manager, systemd-resolved, or a VPN is responsible for the current settings.
Repair DNS at the Configuration Layer That Owns the Machine
A persistent fix belongs in the component that supplies the address. The correct DNS addresses are environment-specific. Use the servers supplied by your network administrator, DHCP service, VPN, or hosting provider, and consider local policy, split DNS, and enterprise filtering before selecting alternatives.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Netplan-managed Ubuntu
Netplan configuration is normally stored as YAML files under /etc/netplan/. List the files and inspect the active interface definition:
ls /etc/netplan
sudo sed -n '1,220p' /etc/netplan/*.yamlFind the interface that carries the default route and its nameservers section. Correct the configured DNS addresses to the approved servers for that network. Preserve the existing indentation and any DHCP, static-address, gateway, VLAN, bridge, or Wi-Fi settings that are unrelated to DNS.
Apply the edited Netplan configuration with the Netplan command appropriate to the machine, normally:
sudo netplan applyOn a remote system, plan for a possible connectivity interruption and use the change procedure appropriate to your provider. After applying the configuration, verify both the link and resolver state:
ip route
resolvectl status
resolvectl query archive.ubuntu.comIf the query succeeds, the nameservers are reachable and the owning configuration is supplying them correctly. If it fails, inspect the per-link DNS shown by resolvectl status and the Netplan file again rather than repeatedly editing /etc/resolv.conf.
systemd-resolved global settings
For a machine whose DNS policy is intentionally managed by systemd-resolved, use a drop-in under /etc/systemd/resolved.conf.d/ instead of modifying a generated resolver file.
sudo mkdir -p /etc/systemd/resolved.conf.d
sudoedit /etc/systemd/resolved.conf.d/ubuntu-dns.confIn that file, create a [Resolve] section and set its DNS= line to the approved upstream server addresses for the machine. Do not copy arbitrary public resolver addresses into a production, VPN, or enterprise environment without checking policy. Save the file, restart the service, and inspect the effective configuration:
sudo systemctl restart systemd-resolved
resolvectl status
resolvectl query archive.ubuntu.comIf the machine receives per-link DNS through DHCP or a VPN, those settings may take precedence for the affected interface. In that case, correct the DHCP, Netplan, network-manager, or VPN profile instead of forcing a global override.
Windows 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 reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteFlush a stale resolver state
When the resolver is running but appears to retain stale data, flushing its cache can be a useful diagnostic step where the command is supported:
sudo resolvectl flush-caches
sudo systemctl restart systemd-resolved
resolvectl query archive.ubuntu.comA successful query after the flush suggests stale state, but it does not replace a durable configuration fix. If the same failure returns after a link change or reboot, repair the component that supplies the DNS servers.
Check APT Sources After DNS Works
Once ordinary hostname lookups work, verify that APT is asking for the right hostnames and Ubuntu release codename. A misspelled, retired, blocked, or organization-specific mirror can produce the same APT wording as a general DNS outage.
Find the source files
Ubuntu 24.04 LTS and later commonly use deb822 source definitions in /etc/apt/sources.list.d/ubuntu.sources. Older releases commonly use /etc/apt/sources.list. Additional files under /etc/apt/sources.list.d/ may define third-party or internal repositories.
grep -RInE '^(Types|URIs|Suites|Components|deb|deb-src)' /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/nullCheck each repository URI character by character, including the hostname, path, and release codename. The standard Ubuntu archive and security hostnames are archive.ubuntu.com and security.ubuntu.com, but an organization may deliberately use an internal mirror. Do not replace an internal source merely because it is not one of the standard public names.
When only one mirror fails
If names for other services resolve but one repository hostname does not, the problem may be limited to that mirror, its DNS zone, or a network policy blocking it. Temporarily selecting the official global archive or another trusted mirror can isolate a mirror-specific problem. Treat that as a diagnostic or interim measure and then correct the source configuration or restore the intended mirror.
Emergency /etc/hosts mapping
Ubuntu community guidance describes mapping a mirror hostname to a known address in /etc/hosts as an emergency workaround. It should be temporary: mirror addresses can change, and a stale mapping can silently send APT to the wrong endpoint. Remove the mapping after the mirror or source configuration is repaired. A hosts entry is not a substitute for fixing DNS or validating repository authenticity.
Why the Browser Can Work While apt-get Fails
A browser and APT do not necessarily use the same path at the same time. The browser may have a cached answer, use a proxy, or be operating through a VPN or per-application network policy. APT normally relies on the system name-service configuration, so its failure should be tested with getent, resolvectl query, and resolvectl status rather than inferred from a browser page loading.
If the browser works but both command-line hostname tests fail, inspect the system resolver and the active link. If command-line tests resolve the name but APT still reports a failure, inspect APT’s source hostname, proxy settings, and whether only one configured repository is unreachable.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Interpret Common Results
No interface address or no default route
Restore the network connection first. Check the physical or virtual link, DHCP lease, Wi-Fi association, virtual machine adapter, container network, or VPN that should provide the route. DNS changes cannot repair a machine that cannot reach any upstream server.
Best Value
Numeric address works, but every hostname fails
This isolates the likely fault to DNS or the local resolver path. Use resolvectl status to identify the configured upstream servers, verify systemd-resolved, and inspect the /etc/resolv.conf link. Then repair Netplan, DHCP, the network manager, VPN, or systemd-resolved configuration that owns those settings.
Only archive.ubuntu.com fails
Check the source spelling and test another known hostname. If other names resolve, investigate the mirror, its DNS zone, or a policy blocking that domain. A temporary trusted mirror change can help distinguish a mirror-specific outage from a machine-wide resolver failure.
Recommended Free Tools
resolvectl shows no usable DNS server
Correct the upstream settings at the owning layer. A local listener at 127.0.0.53 without a working upstream is not sufficient; it only confirms that the local stub is present.
The resolver service is running, but queries remain stale or fail intermittently
Flush caches and restart the service as diagnostic steps, then check per-link settings and DHCP or VPN behavior. If the failure returns after reboot or link changes, stop editing generated files and make the change persistent in the configuration source.
APT reaches a repository but reports a signature problem
This is a separate trust failure. APT verifies repository Release-file signatures and rejects unsigned or unauthenticated repositories by default. Do not use --allow-unauthenticated, Trusted=yes, or other insecure-repository overrides to bypass a DNS error or a signature warning. Restore name resolution first, then resolve any genuine repository-key or signing problem through the repository administrator.
Verify the Repair in the Correct Order
- Confirm an interface address and default route with
ip addrandip route. - Confirm the repository hostname resolves with
getent hosts archive.ubuntu.comorresolvectl query archive.ubuntu.com. - Review the active DNS servers with
resolvectl status. - Check source files for the correct hostnames and release codename.
- Run the index refresh:
sudo apt updateA repaired system should fetch or confirm every configured repository without Temporary failure resolving, Could not resolve, or repeated connection errors. Read the entire output: one successful archive does not prove that every additional source is reachable.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsOnly after the update completes cleanly should you upgrade or install packages:
sudo apt upgradeIf the update still names a single failing source, return to that source’s hostname and mirror configuration. If it names every source, return to the route and resolver checks instead of changing package options.
Prevent the Error From Returning
- Keep DNS changes in Netplan, DHCP, systemd-resolved, the relevant network manager, or the VPN profile that owns them.
- Do not treat a generated
/etc/resolv.confas a permanent configuration file. - Document whether the machine requires internal or split DNS before changing upstream servers.
- Keep Ubuntu source files aligned with the installed release codename and approved mirror policy.
- Remove temporary
/etc/hostsmirror mappings after the underlying issue is fixed. - Leave APT signature verification enabled; DNS repair and repository authentication are separate controls.
Quick Command Checklist
ip addr
ip route
getent hosts archive.ubuntu.com
resolvectl query archive.ubuntu.com
resolvectl status
systemctl status systemd-resolved
ls -l /etc/resolv.conf
cat /etc/resolv.conf
sudo apt update
sudo apt upgradeThe decisive pattern is simple: establish that the link and route work, prove whether hostname lookup works independently of APT, repair the resolver at its owning configuration layer, validate repository source names, and then refresh indexes before upgrading.
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.
