Name Resolution Errors

1. Introduction

Name resolution is an essential service in most environments. It enables users, administrators, and services to contact entities on the network or even locally without remembering addresses on different levels. In practice, to resolve names, we need a mapping between name and address in some kind of database, whether it be a local file such as /etc/hosts or a remote service such as a DNS (name) server. Usually, it’s relatively simpler to perform resolution for local names. However, sometimes, conflicts prevent the proper dynamic mapping even in that case.

In this tutorial, we talk about name resolution and common reasons it might not work. First, we briefly overview name resolution errors. After that, we delve into ways the name we query might be incorrect. Next, we discuss name resolution database issues. Finally, we turn to resolver conflicts.

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. Name Resolution Errors

Typically, if name resolution fails, we see an error from the relevant application.

For instance, in case of such problems, ping usually returns ping: <NAME>: Name or service not known or ping: <NAME>: Temporary failure in name resolution. Further, a tool like ssh may elaborate with custom text such as ssh: Could not resolve hostname <NAME>: Name or service not known. On the other hand, DNS checks with nslookup can output ** server can’t find <NAME>: NXDOMAIN when the host command returns Host <NAME> not found: 3(NXDOMAIN).

While there is only partial standardization, we already see some repetition in terms of the error description. This is due to the similarity of the underlying resolution mechanisms.

Critically, the error mostly depends on the type of name lookup and whether it succeeds:

• <NAME>: Name or service not known indicates that a lookup was performed successfully for NAME, but no mapping between it and an IP address was found
• <NAME>: Temporary failure in name resolution means no lookup was performed due to issues in the resolution system

So, if we encounter a failure like in the first case, we might need to check the current network connection, look at ways to solve DNS issues, verify the local /etc/nsswitch.conf Name Service Switch (NSS) configuration file, ensure proper DNS setup, or similar.

On the other hand, no results after a successful query usually means one of several conditions:

• incorrect name
• incomplete name resolution database
• corrupt name resolution database
• incorrect name resolution database
• name resolution database conflict

In this case, it’s best to take a step-by-step approach.

3. Incorrect Name

Naturally, if we perform a lookup for the wrong name, we might get no result or an unexpected mapping.

However, when it comes to names, we can define wrong in different ways:

• incorrect hostname set
• incorrect hostname published to the resolution database
• mistyped name during the lookup

While the last point has an obvious solution, the other two can be more complex.

First, to set the hostname of a system, we can use different options. More importantly, only some ways are persistent, while others are only temporary. This can lead to a mismatch between what is set and what the system actually uses, depending on the method and state. As a basic example, simply changing the prompt of a shell doesn’t set the hostname:

baeldung@anytext:~ # 

Further, the location where a hostname is applied can have an impact on the way resolution works. If a machine expects to be resolved externally, it needs a published DNS name, not a local hosts file mapping.

4. Name Resolution Database Problems

Sometimes, when a name doesn’t have an address mapping, the reason could lie within the database we query.

One problem can stem from an incomplete database. For instance, we can try to query the local network DNS server for a remote name. While this often causes forwarding or a chain of queries, the exact steps depend on the configuration. So, if the local network DNS database doesn’t have a match, we might still end up with a Name or service not found error. Further, sometimes network problems or misconfiguration can occur within the queried server, not locally.

On the other hand, sometimes, databases get corrupt. In particular, a service malfunction, hardware failure, or other factors can cause a name resolution database to have less information than it normally would. This way, even if we send a correct query, we might get no mapping in reply.

Another problem stems from the database type selection during name resolution. For example, trying to resolve a remote fully qualified domain name (FQDN) via the local hosts file would probably return no results:

$ grep google.com /etc/hosts
$

This is rarely an issue, since the default nsswitch.conf precedence configuration usually lists the local hosts file first, but follows that with *dns in case the local lookup fails. Of course, this means that tools like getent can return an incorrect result from /etc/hosts, which shadows a DNS mapping. However, we still at least get a result.

Although similar in nature, there’s a more specific situation, in which we end up skipping local resolution.

5. Resolver Conflict and Local Router

As we saw, instead of an incorrect name resolution database, the system might point to an incorrect resolver.

Specifically, this sometimes occurs when a router takes over name resolution for a host:

$ nslookup anyhost
Server:         192.168.6.1
Address:        192.168.6.1#53

** server can't find anyhost: NXDOMAIN

Here, we use nslookup for a query. Along with the reply, we get the current resolver address. In this case, 192.168.6.1 is the local router, which means it’s the first point of contact for name resolution requests.

For instance, this can be problematic when we want to perform DNS resolution with a restricted LAN DNS server, which the router won’t forward requests to.

To solve such instances, we can usually turn to the network settings. Specifically, the router-supplied DNS server often gets assigned to systems that match at least one of two criteria:

• no explicit name servers set
• network manager automatically changes the settings

For the first point, we could set a static network configuration. Even then, /etc/resolv.conf is sometimes a symbolic link to another file, handled by an external network manager. To ensure the DNS settings persist, we might need to explicitly remove that link and prevent other applications from handling the nameserver settings.

6. Summary

In this article, we talked about name resolution, errors we might encounter while performing it, and their potential causes.

In conclusion, subtle changes to the network configuration or setup can cause failures when resolving names, so being aware of potential pitfalls can be vital for the correct resolution of names.