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 problemsWhen apt-get prints Temporary failure resolving 'archive.ubuntu.com' or Could not resolve, Ubuntu failed to turn a repository hostname into an IP address. The failure happens before APT can download package indexes, so changing package dependencies or disabling signature checks will not help.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Work from the network upward: confirm the interface and route, test DNS independently, inspect systemd-resolved and /etc/resolv.conf, then repair the configuration layer that owns DNS. Check repository hostnames and release sources after name resolution works. Finish with a clean sudo apt update before upgrading or installing anything.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
What “Unable to Resolve” means in APT
APT retrieves package indexes from repository servers named in Ubuntu’s source configuration. apt update resynchronizes those local indexes; an upgrade should follow only after that synchronization succeeds. A message such as Temporary failure resolving 'archive.ubuntu.com', Could not resolve 'security.ubuntu.com', or Unable to resolve host means hostname lookup failed while APT was trying to contact a repository.
That places the problem in one of four areas:
- The machine has no working interface, default route, or upstream Internet path.
- The configured DNS server is unreachable, incorrect, or refusing the query.
- The local resolver service or its configuration is stale or broken.
- The APT source contains a misspelled, retired, blocked, or otherwise unreachable repository hostname.
It is not the same as a dependency conflict, a malformed package, or a repository-signature failure. Those occur after APT has reached a server and received metadata. Diagnose connectivity and name resolution before changing packages or repository trust settings.
Start with a safe diagnostic sequence
Run these checks in order. Each one narrows the fault without changing system configuration.
1. Confirm the interface and default route
First check whether Ubuntu has an address on the expected interface and a route for traffic leaving the local network:
ip addr
ip routeLook for an interface that is up and has an address appropriate to your LAN, virtual machine, server network, or VPN. In ip route output, a line beginning with default via identifies the gateway used for destinations outside the local subnet. If there is no usable address or no default route, DNS changes cannot solve the underlying problem. Fix the link, DHCP lease, virtual-network attachment, Wi-Fi association, or VPN connection first.
To separate general reachability from DNS, test a numeric address that you know is reachable from this machine and network. A numeric-address test does not require hostname lookup. If the numeric test fails, investigate routing, firewall rules, the gateway, or the upstream connection. If it succeeds while hostname tests fail, DNS becomes the leading suspect. ICMP may be filtered, so treat a failed ping as evidence to investigate rather than absolute proof that every kind of traffic is blocked.
2. Test name resolution without APT
Use the resolver tools directly:
getent hosts archive.ubuntu.com
resolvectl query archive.ubuntu.com
ping -c 1 archive.ubuntu.comgetent tests the name-service path used by ordinary applications. resolvectl query asks the resolver service directly and normally gives a clearer error or answer. ping combines lookup with an ICMP reachability test; a successful lookup followed by a timeout still proves that DNS returned an address.
Repeat the query for another known hostname, such as security.ubuntu.com. If all names fail, suspect the local resolver, its upstream servers, or the network path to DNS. If one name fails while others resolve, inspect that repository hostname for a typo, retired mirror, DNS filtering, or a mirror outage.
3. Inspect systemd-resolved
On current Ubuntu installations, systemd-resolved commonly supplies the local resolver. Check both its service state and the DNS information it has learned:
systemctl status systemd-resolved
resolvectl statusresolvectl status shows global and per-link DNS servers, search domains, and which interface is being used. Servers may have come from DHCP, a Netplan definition, a VPN, a network-management service, or global resolver settings. A service can be running while still having no usable upstream DNS server, so the two commands must be read together.
The address 127.0.0.53, often shown in Ubuntu’s resolver configuration, is a local systemd-resolved stub listener. It is not the upstream DNS server on the Internet or on your organization’s network. Do not replace it with a random address merely because it appears in an error message; find the actual upstream servers in resolvectl status and in the configuration layer that supplied them.
4. Inspect, but do not blindly overwrite, resolv.conf
Check what /etc/resolv.conf is and what it contains:
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →ls -l /etc/resolv.conf
cat /etc/resolv.confOn a systemd-resolved setup, the file may be a symbolic link to /run/systemd/resolve/stub-resolv.conf or /run/systemd/resolve/resolv.conf. Those generated files reflect resolver state and can change when a link, DHCP lease, VPN, or service changes. A hand-edited file may appear to fix one query and then be replaced at reboot or during the next network event.
If the link points somewhere unexpected, record the current state before changing it. Determine whether Netplan, DHCP, a VPN client, or another network service owns the setting. Persistent repairs belong there, not in a generated file that another service controls.
Use the results to identify the fault
| Observed result | Most likely area | Next action |
|---|---|---|
No interface address or no default via route |
Link, DHCP, virtual network, gateway, or VPN | Restore the interface and route before testing DNS again. |
Numeric-address connectivity works; getent and resolvectl query fail for every hostname |
DNS server, systemd-resolved, or resolver configuration | Read resolvectl status, inspect resolv.conf, and repair the owning configuration layer. |
| Some names resolve but one repository name fails | Typo, retired mirror, blocked DNS zone, or mirror-specific outage | Inspect the APT source and test the failing hostname separately. |
| Names resolve, but APT reports connection timeouts or refused connections | Firewall, proxy, route, server availability, or mirror policy | Investigate transport and repository access; this is no longer a pure DNS failure. |
| APT downloads metadata but rejects a Release file | Repository authentication or signing configuration | Keep signature verification enabled and address the trust error separately. |
Apply a durable DNS repair
Change DNS where it is administered. The correct method depends on how the machine receives network configuration. DNS addresses below are examples only; use servers approved for your network, VPN, and security policy.
Netplan-managed Ubuntu
Netplan systems keep interface configuration in YAML files under /etc/netplan/. Open the file that defines the affected interface and correct its nameservers addresses. A typical structure looks like this:
network:
version: 2
ethernets:
enp1s0:
dhcp4: true
nameservers:
addresses:
- 10.0.0.53
- 10.0.0.54The interface name and whether DHCP is enabled will differ on your machine. Replace the example addresses with reachable, authorized DNS servers; do not copy them unless they are genuinely provided by your network. Preserve YAML indentation. A syntax mistake can affect the entire interface configuration, so review the file before applying it.
Apply the change with:
sudo netplan applyOn a remote system, use a change procedure that preserves console access in case the network drops. After applying, run resolvectl status and resolvectl query archive.ubuntu.com. The expected result is that the affected link lists the intended DNS servers and the query returns one or more addresses.
systemd-resolved global settings
If the machine intentionally uses systemd-resolved global configuration, create a drop-in rather than editing a generated resolver file:
sudo mkdir -p /etc/systemd/resolved.conf.d
sudo nano /etc/systemd/resolved.conf.d/ubuntu-dns.confPut a [Resolve] section in the file and specify approved servers:
[Resolve]
DNS=10.0.0.53 10.0.0.54Save the file, restart the service, and inspect the active state:
sudo systemctl restart systemd-resolved
resolvectl status
resolvectl query archive.ubuntu.comUse this method only when global systemd-resolved settings are the right owner. A per-link DNS policy supplied by DHCP or a VPN may deliberately override global servers. Enterprise networks can also require split DNS, where internal names must go to an internal resolver while public names use another path. Replacing those settings with a public resolver can break internal access or violate policy.
DHCP, VPN, and other network managers
If resolvectl status shows DNS servers arriving with a link, DHCP lease, or VPN, correct that source instead of forcing a global override. Check the network profile or VPN configuration for an incorrect DNS address, an expired lease, or a tunnel that is connected without installing its DNS routes. Disconnecting a VPN temporarily can establish whether it owns the failing resolver path; reconnect it only after its DNS policy is corrected.
After changing the owning profile, renew the connection or lease using the management method appropriate to that system, then verify with resolvectl status. Avoid running several competing tools that each rewrite DNS; they can produce intermittent results that disappear after the next link change.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Flush stale resolver state when appropriate
If the service is healthy and the configuration is correct but answers remain stale, flush the resolver cache where supported:
sudo resolvectl flush-caches
resolvectl query archive.ubuntu.comA service restart can also be diagnostic:
sudo systemctl restart systemd-resolvedFlushing a cache cannot repair a missing route, a wrong upstream server, or a misspelled repository. Use it after correcting those causes, not as a substitute for finding them.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Check APT sources and mirrors after DNS works
Once ordinary hostname queries succeed, inspect the repository definitions. APT can report the same resolution error for a single bad mirror even when the rest of the network is healthy.
Find the source file and hostname
Ubuntu 24.04 LTS and later commonly use deb822 source files such as /etc/apt/sources.list.d/ubuntu.sources. Older releases commonly use /etc/apt/sources.list, with additional entries possibly under /etc/apt/sources.list.d/. Review the active files for misspelled hostnames, an incorrect release codename, or a source that no longer exists.
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 reinstallOutdated 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 matchgrep -RniE 'archive.ubuntu.com|security.ubuntu.com|URIs:|Suites:' /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/nullThe standard Ubuntu archive and security hosts are archive.ubuntu.com and security.ubuntu.com, but an organization may intentionally use an internal mirror. Do not replace an internal host simply because it is unfamiliar; confirm the intended source with the system owner.
Isolate a mirror-specific failure
If resolvectl query succeeds for other names but one mirror does not resolve, test that mirror directly and inspect its source entry. A temporarily selected official global archive or another trusted mirror can help determine whether the problem is limited to one mirror. Make the change in the source file, record what you changed, and restore the organization’s intended mirror once it is available.
Best Value
An /etc/hosts mapping can be an emergency workaround for a known-bad mirror, but it requires a verified current numeric address and should not become a permanent substitute for DNS. Add the hostname only with an address obtained from a trusted, current source; remove the line after fixing the mirror or source configuration. A stale mapping can silently send package traffic to the wrong server.
Check the release codename
A hostname may resolve correctly while the source still names the wrong Ubuntu release. In deb822 files, review the Suites: value; in traditional entries, review the distribution codename between the repository URL and component names. Do not change a codename merely to make an update proceed. Use the codename that matches the installed Ubuntu release and the repository’s documented support.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Why the browser can work while apt-get fails
A working browser does not prove that the system resolver used by APT is healthy. The browser may still have a cached address or an existing connection, or it may use a resolver path separate from the operating system’s resolver. APT normally follows Ubuntu’s system name-service configuration, so a broken systemd-resolved state, an invalid resolv.conf link, or a DNS policy that affects command-line applications can stop APT while a previously opened web page continues loading.
Test the exact repository hostname with getent and resolvectl query rather than using a browser as the diagnostic. If those commands fail, fix system DNS. If they succeed but APT still cannot connect, examine proxy settings, firewall rules, IPv4/IPv6 routing, and the mirror’s availability. Those are transport problems, not hostname-resolution problems.
Do not confuse DNS failures with repository authentication
DNS resolution happens before APT can retrieve a Release file. Once a server responds, APT verifies Release-file signatures and can reject unsigned or unauthenticated repositories. The resulting messages mention signatures, authentication, or a changed Release file rather than “Temporary failure resolving.”
Never use --allow-unauthenticated, Trusted=yes, or other insecure-repository overrides to bypass a resolver error. Those options weaken package authenticity checks and cannot make an unresolvable hostname reachable. Restore DNS and correct the source or mirror, then address any separate signature error according to the repository’s legitimate key and release process.
Free tools Windows power users keep installed
One-click scans. No signup required.
Verify the repair in the correct order
After network, resolver, and source corrections, run:
sudo apt updateA successful run should fetch or use cached metadata for every configured repository without Temporary failure resolving, Could not resolve, repeated connection failures, or a source-specific error. Read the complete output; one repository can fail even when others succeed.
Only after the update is clean should you continue with:
sudo apt upgradeFor a package installation, use the same order: resolve the network and source issue, complete apt update, then install the package. If the update reports a Release-file signature problem after DNS is fixed, stop and handle that trust issue separately rather than applying an authentication bypass.
Quick Recap
A recovery checklist for administrators
- Capture the exact APT message and the hostname it could not resolve.
- Run
ip addrandip route; restore the interface address or default route if either is missing. - Test the hostname with
getent hostsandresolvectl query. - Read
resolvectl statusto identify active global and per-link DNS servers. - Check the
/etc/resolv.confsymlink and contents without replacing a generated file blindly. - Repair Netplan, DHCP, VPN, or systemd-resolved configuration according to whichever component owns DNS.
- Flush caches or restart systemd-resolved only after the configuration is correct.
- Inspect Ubuntu source files for typos, retired mirrors, blocked zones, and incorrect release suites.
- Use an emergency hosts mapping only with a verified address, and remove it after the underlying issue is fixed.
- Run
sudo apt update, confirm every configured source succeeds, and only then upgrade or install packages.
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.
