What is a DNS resolver?

DNS resolvers are an essential component of the Domain Name System (DNS). They act as the querying coun­ter­part to the re­spond­ing DNS nameserv­ers. From the user’s point of view, a DNS resolver serves as an interface between the user or ap­plic­a­tion and the nameserv­ers.

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 spe­cific­a­tion document RFC 1034:

DNS resolvers are the coun­ter­part to nameserv­ers, which contain the actual DNS in­form­a­tion. Since nameserv­ers are also referred to as DNS servers, the term `DNS client´ is oc­ca­sion­ally 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 ne­ces­sar­ily a single component, nor is it a specific tech­no­logy. From the user’s per­spect­ive, a DNS resolver is any system that de­term­ines an IP address for a domain name. It does not matter how exactly the DNS resolver obtains the in­form­a­tion.

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 com­mu­nic­ate with DNS resolvers located on remote systems, which do the actual name res­ol­u­tion work.

The Domain Name System (DNS) is a hier­arch­ic­al system dis­trib­uted around the world for managing data as­so­ci­ated 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 res­ol­u­tion, i.e. the mapping of domain names to IP addresses. DNS resolvers are therefore one of the corner­stones of the technical structure of the internet. Here is an example of name res­ol­u­tion:

Although most users may not be aware of it, many daily op­er­a­tions begin with resolving a domain name to an IP address. Accessing a website, re­triev­ing emails, or logging into a user account via an app all begin with name res­ol­u­tion 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 com­mu­nic­ates with. To com­mu­nic­ate, 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. For­tu­nately, DNS resolvers exist and can deal with the name res­ol­u­tion task.

It is possible to get by without a DNS resolver. It is possible to use IP addresses directly, however, this only works the­or­et­ic­ally nowadays. In practice, you would ex­per­i­ence con­sid­er­able losses if there were no name res­ol­u­tion.

First, the secure HTTPS protocol is bound to domain names. If you try to query a website with a blank IP, encrypted com­mu­nic­a­tion will not be possible. Fur­ther­more, by assigning domain names, it makes it possible to host several websites on one server and to address them spe­cific­ally.

Modern ap­proaches to the geo­graph­ic­al dis­tri­bu­tion of server resources also require access to a DNS resolver. Here, a single domain name is as­so­ci­ated with several IP addresses. This can be well il­lus­trated using Google’s website as an example. If this were only ac­cess­ible under a single IP address, the worldwide traffic would ac­cu­mu­late in this one place and the system would soon be over­loaded.

The Domain Name System (DNS) consists of globally dis­trib­uted com­pon­ents that interact with each other. There are four main classes of com­pon­ents, of which three are nameserv­ers that contain DNS records. The remaining class includes the DNS resolvers, which are the coun­ter­part to the nameserv­ers.

As you already know, a DNS resolver receives a domain name as a request and has the task of de­term­in­ing 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 nameserv­ers and compiles an answer from the in­form­a­tion it obtains. The algorithm used for name res­ol­u­tion 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 nameserv­ers to query.
3. Send queries to the nameserv­ers 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 nameserv­ers, 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 as­so­ci­ated name res­ol­u­tion are important when surfing the internet. At the same time, DNS is notorious for being error prone.

This sus­cept­ib­il­ity to errors is inherent in the nature of the system. The DNS is a globally dis­trib­uted, hier­arch­ic­ally organised system where changes propagate gradually. This can take up to 48 hours, so dis­crep­an­cies can easily occur. Fur­ther­more, caches are used at all levels, which are critical for per­form­ance, 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 com­mu­nic­a­tion. The User Datagram Protocol (UDP) is simpler and less resource intensive. Un­for­tu­nately, it is precisely these char­ac­ter­ist­ics that make public DNS resolvers at­tract­ive targets for cy­ber­crim­in­als.

The UDP flood attack variant is used to abuse public DNS resolvers as amp­li­fi­ers for DDoS attacks. Fur­ther­more, there are cache poisoning attacks where fake DNS in­form­a­tion is smuggled to DNS resolvers. Source port ran­dom­isa­tion is therefore used as a pro­tect­ive measure at server level.

If strange errors occur on the local system that could hint at DNS being the cause, it is re­com­men­ded to first check whether the name res­ol­u­tion 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 res­ol­u­tion works, we receive a cor­res­pond­ing IP address as a response. Fur­ther­more, the tool issues the con­figured DNS resolver:

Con­veni­ently, 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 al­tern­at­ive to nslookup, a ping can be executed against the domain name. The ping command is pre-installed on most systems and triggers name res­ol­u­tion when accessed. The hostname is passed as an argument:

If nslookup or ping do not return an IP address, it seems that the name res­ol­u­tion 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 res­ol­u­tion at least works in principle. Nev­er­the­less, the in­form­a­tion may be wrong. To evaluate the delivered result, it makes sense to compare it with globally stored DNS entries. We use the DNS Propaga­tion 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 con­figured in the system, which deals with the name res­ol­u­tion 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 re­spect­ive internet provider is used on most systems, whether PC, laptop, or smart­phone. 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 dis­ad­vant­age­ous.

In addition to the pos­sib­il­ity of per­son­ally as­signable DNS in­form­a­tion being tapped i.e. a DNS leak, there is also the chance of DNS spoofing. In this case, the internet provider delivers ma­nip­u­lated DNS data to the user. For example, com­pet­it­ors are blocked, or internet traffic is re­dir­ec­ted to sites with ad­vert­ise­ments. 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 con­nec­tion 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 re­dund­ancy 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 res­ol­u­tion cannot work without a DNS resolver, human-friendly names cannot logically be used.

Free DNS resolvers offer several ad­vant­ages. In addition to higher speed and privacy pro­tec­tion, they partly offer filter functions. Well-known examples are Cloud­flare 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 situ­ations where it makes sense to bypass name res­ol­u­tion 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 man­age­able. To resolve host names into IP addresses, the cor­res­pond­ing com­bin­a­tions 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 con­figured like this:

For name res­ol­u­tion, 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 as­so­ci­ated IP address. In this case, the query remains entirely on the local machine. Otherwise, the normal name res­ol­u­tion process takes place via the con­figured 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 ap­plic­a­tions. Since the hosts file is evaluated first, it can be used as a work­around 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 peri­od­ic­ally check in with a server con­figured 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 il­lus­trate 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 con­nec­tion 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-sanc­tioned 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 de­vel­op­ment approach to configure name res­ol­u­tion 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 in­stall­a­tion, 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 ac­cess­ible 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 de­vel­op­ment en­vir­on­ment that is ac­cess­ible at the loopback address 127.0.0.1. In the hosts file, we add an entry for the hostname dev.example.com: