Temporary Failure Resolving and Package Manager Name Resolution Issues

1. Introduction

Most services and applications that conduct network operations require name resolution to function correctly. Package managers are no exception. So, if an environment has an incorrect domain name system (DNS) configuration or another problem that blocks remote name resolution, we might not be able to make full use of many local services and applications.

In this tutorial, we talk about problems with name resolving and discuss their effect on package management. First, we explain the link between package managers and name resolution. After that, we check some common package manager errors that can be caused by failures when resolving names. Next, we delve into connectivity issues as the root cause of such errors. Then, we explore source misconfiguration. Finally, we turn to package-manager-specific proxies as potential culprits.

We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. Unless otherwise specified, it should work in most POSIX-compliant environments.

2. Package Manager Name Resolution

Apart from offline package installation and other local operations, package managers perform multiple tasks over the network:

• repository verification
• package list updates
• package download
• dependency resolution

All of these activities require sources. Many times, such sources are in the form of an Internet URL, which also contains a domain name. Because of this, domain name resolution can be critical to the functionality of a package manager.

For instance, let’s check the current APT sources list:

$ cat /etc/apt/sources.list
deb http://deb.debian.org/debian stable main non-free-firmware
deb-src http://deb.debian.org/debian stable main non-free-firmware

So, if we can’t get the IP address of debian.org as the domain name for all of our sources, we won’t be able to get any package lists or download new packages.

3. Package Manager Name Resolution Errors

Although not specific to package managers, name resolution issues have fairly common error descriptions:

• apt: Temporary Failure Resolving <NAME>
• dnf (yum): Couldn’t resolve host name for <NAME> (due to curl backend)
• dnf (yum): Could not resolve host: <NAME>
• pacman: Could not resolve host: <NAME>
• snapd: lookup <NAME> on [::1]:53: read udp [::1]:66601->[::1]:53: read: connection refused

Interestingly, Snap falls back to local stub resolver resolution and only gives up when that fails, so this is the last error we see.

Still, some of these errors are the same for other applications and services as well. Further, many are a sign of the underlying mechanism for downloading or sending remote requests.

How we correct such problems depends on the underlying cause. Let’s go over several typical scenarios.

4. Connectivity Issues

Perhaps the simplest reason for DNS resolution failure is the inability to reach an external DNS server.

4.1. Bad Network or Internet Connection

To begin with, let’s check our Internet connectivity:

$ ping 1.1.1.1
ping: connect: Network is unreachable

Here, we use ping to check the connection to a reliable remote server. Specifically, we use the DNS server of a content delivery company. In this case, there is no connection, which indicates a deeper issue.

Naturally, we won’t be able to reach any server if the network or Internet connection isn’t working. Why that could be and how to fix it is beyond the scope of this article.

Once the connection is back up, if we still experience issues, we continue with other checks.

4.2. Default DNS Server Connection

Even when we do have stable network connectivity, DNS or name servers can still be out of reach.

If we’re unable to contact a DNS or other name server, we might not be able to resolve the relevant source or repository name:

$ nslookup debian.org
Server:         208.67.222.222
Address:        208.67.222.222#53

** server can't find debian.org: SERVFAIL

In this case, the SERVFAIL output from nslookup confirms we can’t even connect to the default DNS server.

So, we might need to change our DNS server. For instance, we can set the previously mentioned 1.1.1.1 in our /etc/resolv.conf:

$ echo 'nameserver 1.1.1.1' >> /etc/resolv.conf

Of course, how we do that depends on our system and DNS configuration, since some environments have automated network managers.

In addition, our ISP might be blocking requests to certain DNS services or over some ports.

5. Sources Misconfiguration

Although rare, package manager sources can be configured incorrectly or can become corrupt.

For example, let’s explore another basic APT sources file:

$ cat /etc/apt/sources.list
deb http://deb.debian.orgdebian stable main non-free-firmware
deb-src http://deb.debian.orgdebian stable main non-free-firmware

Notably, the forward slash is missing after org in each repository URL.

Now, we can try to update the package lists using apt:

$ apt update
[...]
W: Failed to fetch http://deb.debian.orgdebian/dists/[...]/InRelease  Could not resolve 'deb.debian.orgdebian'
W: Failed to fetch http://deb.debian.orgdebian/dists/[...]-updates/InRelease  Could not resolve 'deb.debian.orgdebian'
W: Failed to fetch http://deb.debian.orgdebian-security/dists/[...]-security/InRelease  Could not resolve 'deb.debian.orgdebian-security'
W: Some index files failed to download. They have been ignored, or old ones used instead.

As expected, the system can’t resolve the incorrect domain from the source URL. Such problems can exist in the /etc/apt/sources.list.d/ files as well.

Looking closely at the unresolvable names (NAME in the examples from earlier) can hint at the problematic repositories.

In case we make changes to the current source files, we run apt clean and apt update to ensure the modifications are in effect.

6. Proxy Configuration

Although this is related to connectivity, it’s a special scenario: some package managers enable the configuration of an exclusive proxy specific that only affects them.

For example, APT supports proxies and can use its /etc/apt/apt.conf.d/ directory to store such settings:

$ cat /etc/apt/apt.conf.d/*proxy*
Acquire::http::Proxy "http://<USERNAME>:<PASSWORD>@<PROXY_HOSTNAME>:<PROXY_PORT>/";
Acquire::https::Proxy "https://<USERNAME>:<PASSWORD>@<PROXY_HOSTNAME>:<PROXY_PORT>/";
Acquire::ftp::Proxy "ftp://<USERNAME>:<PASSWORD>@<PROXY_HOSTNAME>:<PROXY_PORT>/";

Similarly, there are ways to set a proxy for other package managers.

This is important since malfunctioning proxies can block or filter the network connection, thereby preventing remote name resolutions.

7. Summary

In this article, we looked at ways to identify, solve, or work around problems related to resolving names when it comes to package managers.

In conclusion, name resolution is critical to many system activities, including package acquisition and updates, so knowing how to handle problems with it can be vital.