What is a DNS resolver?

DNS resolvers are an essential component of the Domain Name System (DNS). They act as the querying counterpart to the responding DNS nameservers. From the user’s point of view, a DNS resolver serves as an interface between the user or application and the nameservers.

A DNS resolver is a service that provides an IP address on request for a domain name. This is referred to as a domain being resolved to an IP address. This is defined in the internet specification document RFC 1034:

DNS resolvers are the counterpart to nameservers, which contain the actual DNS information. Since nameservers are also referred to as DNS servers, the term `DNS client´ is occasionally used for DNS resolvers. However, many DNS resolvers are servers, which shows that the term DNS server has multiple uses.

DNS resolvers come in many different forms. A DNS resolver is not necessarily a single component, nor is it a specific technology. From the user’s perspective, a DNS resolver is any system that determines an IP address for a domain name. It does not matter how exactly the DNS resolver obtains the information.

At the lowest level there are the `stub resolvers´. This is usually a software library or service that runs on the local system. Stub resolvers usually communicate with DNS resolvers located on remote systems, which do the actual name resolution work.

The Domain Name System (DNS) is a hierarchical system distributed around the world for managing data associated with internet domains. A domain is a human-friendly name that is easy to remember and can be typed in manually. One of the main tasks of the DNS is name resolution, i.e. the mapping of domain names to IP addresses. DNS resolvers are therefore one of the cornerstones of the technical structure of the internet. Here is an example of name resolution:

Although most users may not be aware of it, many daily operations begin with resolving a domain name to an IP address. Accessing a website, retrieving emails, or logging into a user account via an app all begin with name resolution and only then does the actual data transfer take place.

What the above steps have in common is that servers are involved. In other words, remote systems that our local system communicates with. To communicate, you need the other party’s address, which in this case is the server’s IP address. However, we usually only know their domain names. Fortunately, DNS resolvers exist and can deal with the name resolution task.

It is possible to get by without a DNS resolver. It is possible to use IP addresses directly, however, this only works theoretically nowadays. In practice, you would experience considerable losses if there were no name resolution.

First, the secure HTTPS protocol is bound to domain names. If you try to query a website with a blank IP, encrypted communication will not be possible. Furthermore, by assigning domain names, it makes it possible to host several websites on one server and to address them specifically.

Modern approaches to the geographical distribution of server resources also require access to a DNS resolver. Here, a single domain name is associated with several IP addresses. This can be well illustrated using Google’s website as an example. If this were only accessible under a single IP address, the worldwide traffic would accumulate in this one place and the system would soon be overloaded.

The Domain Name System (DNS) consists of globally distributed components that interact with each other. There are four main classes of components, of which three are nameservers that contain DNS records. The remaining class includes the DNS resolvers, which are the counterpart to the nameservers.

As you already know, a DNS resolver receives a domain name as a request and has the task of determining an IP address to go with it. So how exactly does the process work? There are several ways to proceed.

If the request has already been made before, e.g. if google.com has been visited a number of times, the response is loaded from the local cache. If this is not the case, the resolver makes queries to nameservers and compiles an answer from the information it obtains. The algorithm used for name resolution is defined in RFC 1034:

1. Check whether the desired response is contained in the local cache. If so, deliver the response to the client.
2. Identify the best nameservers to query.
3. Send queries to the nameservers until one delivers a response.
4. Evaluate the answer; then:
   1. If the response resolves the query or contains a name error, cache the response and deliver it to the client.
   2. If the response contains a reference to other nameservers, cache the response and proceed to step (2).
      1. If the response is a CNAME record, cache the CNAME and continue with the canonical name in step (1).
   3. If the response contains a server error, or appears to be incorrect, remove the server from the server list and proceed to step (3).

As we have seen, DNS resolvers and the associated name resolution are important when surfing the internet. At the same time, DNS is notorious for being error prone.

This susceptibility to errors is inherent in the nature of the system. The DNS is a globally distributed, hierarchically organised system where changes propagate gradually. This can take up to 48 hours, so discrepancies can easily occur. Furthermore, caches are used at all levels, which are critical for performance, but are again a source of errors.

Unlike the actual exchange of data on the internet, which mainly runs via the TCP/IP protocol, UDP is used for DNS communication. The User Datagram Protocol (UDP) is simpler and less resource intensive. Unfortunately, it is precisely these characteristics that make public DNS resolvers attractive targets for cybercriminals.

The UDP flood attack variant is used to abuse public DNS resolvers as amplifiers for DDoS attacks. Furthermore, there are cache poisoning attacks where fake DNS information is smuggled to DNS resolvers. Source port randomisation is therefore used as a protective measure at server level.

If strange errors occur on the local system that could hint at DNS being the cause, it is recommended to first check whether the name resolution is working. This is easy to do and will quickly give you clues about possible problems.

On almost all systems, the nslookup tool is available as a command line program. In the simplest case we run the tool and pass the desired hostname as an argument. If the name resolution works, we receive a corresponding IP address as a response. Furthermore, the tool issues the configured DNS resolver:

Conveniently, nslookup can also be used for reverse DNS lookup. In this case we pass an IP address as an argument and get one or more names returned:

As an alternative to nslookup, a ping can be executed against the domain name. The ping command is pre-installed on most systems and triggers name resolution when accessed. The hostname is passed as an argument:

If nslookup or ping do not return an IP address, it seems that the name resolution isn’t working. In this case it is worth trying to change the DNS resolver or to create a temporary entry in the hosts file. More about this below.

If an IP address is displayed, it means that the name resolution at least works in principle. Nevertheless, the information may be wrong. To evaluate the delivered result, it makes sense to compare it with globally stored DNS entries. We use the DNS Propagation Checker from whatsmydns.net to show us the A-records for the hostname.

As we said at the beginning, the term DNS resolver has several meanings. When we talk about changing the DNS resolver, we mean the address of the server configured in the system, which deals with the name resolution for us. Most users are probably not aware that an external server is used for this purpose.

In the default state, the DNS resolver of the respective internet provider is used on most systems, whether PC, laptop, or smartphone. In home networks, the IP address of the DNS resolver is usually stored in the router. However, using the preset DNS resolver can be quite disadvantageous.

In addition to the possibility of personally assignable DNS information being tapped i.e. a DNS leak, there is also the chance of DNS spoofing. In this case, the internet provider delivers manipulated DNS data to the user. For example, competitors are blocked, or internet traffic is redirected to sites with advertisements. It is therefore generally a good idea to set the DNS resolver yourself.

To change the DNS resolver, there are different ways to proceed depending on the operating system. It usually requires you to configure the network connection and enter the internet address of a known DNS resolver. Analogous to secondary DNS, a secondary server is entered next to the primary DNS resolver. This provides redundancy and protects against errors if the DNS server does not respond.

To change the DNS resolver, you need to know the exact IP addresses of one or more servers running a DNS resolver. Since name resolution cannot work without a DNS resolver, human-friendly names cannot logically be used.

Free DNS resolvers offer several advantages. In addition to higher speed and privacy protection, they partly offer filter functions. Well-known examples are Cloudflare with the identical IP address 1.1.1.1 and Quad9 with 9.9.9.9.

As we have seen, DNS resolvers are essential for working with the internet. However, there are some situations where it makes sense to bypass name resolution via DNS resolver. The technical trick is to make entries in the hosts file.

The hosts file is a relic from the early days of the internet. At that time, there was no DNS, but the number of connected computers was manageable. To resolve host names into IP addresses, the corresponding combinations were entered directly into the hosts file. A single IP address is on the left, one or more hostnames on the right. The hostname localhost for the `Loopback Interface´ is often configured like this:

For name resolution, the local stub DNS resolver evaluates the entries of the hosts file. If a match is found for the queried host name, the stub resolver returns the associated IP address. In this case, the query remains entirely on the local machine. Otherwise, the normal name resolution process takes place via the configured external DNS resolver.

The hosts file makes it possible to work without a DNS resolver. However, this requires you to create an entry for each hostname to be resolved. This is not very practical for daily work, but it is well suited for special applications. Since the hosts file is evaluated first, it can be used as a workaround for various problems.

One use of the host file is to assign a fixed IP address to a host name. This trick is often used to mute apps that `phone home´. This is because some apps periodically check in with a server configured by hostname and transmit data unchecked. If you want to prevent this, all you need to do is make an entry in the hosts file.

Allow us to illustrate the principle with an example. We want to prevent a local program from accessing spy.example.com. To do this, we enter the domain name in the hosts file and point to the loopback IP 127.0.0.1. This way, the requests go to the local system and never reach the server. From the app’s point of view, the requests get stuck, as if the internet connection is down, for example:

The principle can also be reversed. In many countries today, web blocking is used at the DNS level. Internet providers are forced by court order to deliver no IP addresses or falsified IP addresses for certain domain names. Strictly speaking, this is state-sanctioned DNS spoofing. From the user’s point of view, the desired domains cannot be accessed.

The clever use of the hosts file on your own system enables you to bypass DNS-based web blocking. All you need is the actual IP address of the blocked website. This is entered into the hosts file together with the domain name. For example, let’s assume that the domain blocked.example.com is blocked by the provider via DNS web blocking. If we enter the IP address of the site in the hosts file, it will be possible to access it again.

Last but not least, a web development approach to configure name resolution on the local device via hosts file. Let’s assume the plan is to migrate an existing website under the domain www.example.com. To prepare for the migration, we first transfer the site to the new server. Now we need to test the installation, but there is a problem because the existing site on the old server 93.184.216.34 is still being accessed under the domain name. Migrating the site to the new server cannot be tested this way.

So we simply enter the IP address of the new server along with the domain name in the hosts file. This way our local requests will go to the new server and we can test without any problems. At the same time, all other visitors continue to get the IP address of the old server delivered to them. This way the site remains fully accessible for visitors.

A similar approach is used to develop a staging site locally. Let’s imagine that the site at www.example.com is to be rebuilt. We set up a staging site in a local development environment that is accessible at the loopback address 127.0.0.1. In the hosts file, we add an entry for the hostname dev.example.com: