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 name­servers. From the user’s point of view, a DNS resolver serves as an interface between the user or ap­pli­ca­tion and the name­servers.

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 spec­i­fi­ca­tion document RFC 1034:

DNS resolvers are the coun­ter­part to name­servers, which contain the actual DNS in­for­ma­tion. Since name­servers are also referred to as DNS servers, the term “DNS client” is oc­ca­sion­al­ly 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 nec­es­sar­i­ly a single component, nor is it a specific tech­nol­o­gy. From the user’s per­spec­tive, a DNS resolver is any system that de­ter­mines an IP address for a domain name. It does not matter how exactly the DNS resolver obtains the in­for­ma­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­ni­cate with DNS resolvers located on remote systems, which do the actual name res­o­lu­tion work.

The Domain Name System (DNS) is a hi­er­ar­chi­cal system dis­trib­uted around the world for managing data as­so­ci­at­ed 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­o­lu­tion, i.e. the mapping of domain names to IP addresses. DNS resolvers are therefore one of the cor­ner­stones of the technical structure of the internet. Here is an example of name res­o­lu­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­o­lu­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­ni­cates with. To com­mu­ni­cate, 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­nate­ly, DNS resolvers exist and can deal with the name res­o­lu­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­o­ret­i­cal­ly nowadays. In practice, you would ex­pe­ri­ence con­sid­er­able losses if there were no name res­o­lu­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­ni­ca­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 specif­i­cal­ly.

Modern ap­proach­es to the ge­o­graph­i­cal dis­tri­b­u­tion of server resources also require access to a DNS resolver. Here, a single domain name is as­so­ci­at­ed with several IP addresses. This can be well il­lus­trat­ed using Google’s website as an example. If this were only ac­ces­si­ble 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­po­nents that interact with each other. There are four main classes of com­po­nents, of which three are name­servers that contain DNS records. The remaining class includes the DNS resolvers, which are the coun­ter­part to the name­servers.

As you already know, a DNS resolver receives a domain name as a request and has the task of de­ter­min­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 name­servers and compiles an answer from the in­for­ma­tion it obtains. The algorithm used for name res­o­lu­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 name­servers to query.
3. Send queries to the name­servers 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 name­servers, 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­at­ed name res­o­lu­tion are important when surfing the internet. At the same time, DNS is notorious for being error prone.

This sus­cep­ti­bil­i­ty to errors is inherent in the nature of the system. The DNS is a globally dis­trib­uted, hi­er­ar­chi­cal­ly organized 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­for­mance, 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­ni­ca­tion. The User Datagram Protocol (UDP) is simpler and less resource intensive. Un­for­tu­nate­ly, it is precisely these char­ac­ter­is­tics that make public DNS resolvers at­trac­tive targets for cy­ber­crim­i­nals.

The UDP flood attack variant is used to abuse public DNS resolvers as am­pli­fiers for DDoS attacks. Fur­ther­more, there are cache poisoning attacks where fake DNS in­for­ma­tion is smuggled to DNS resolvers. Source port ran­dom­iza­tion is therefore used as a pro­tec­tive measure at server level.

If strange errors occur on the local system that could hint at DNS being the cause, it is rec­om­mend­ed to first check whether the name res­o­lu­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­o­lu­tion works, we receive a cor­re­spond­ing IP address as a response. Fur­ther­more, the tool issues the con­fig­ured DNS resolver:

Con­ve­nient­ly, 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­ter­na­tive to nslookup, a ping can be executed against the domain name. The ping command is pre-installed on most systems and triggers name res­o­lu­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­o­lu­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­o­lu­tion at least works in principle. Nev­er­the­less, the in­for­ma­tion may be wrong. To evaluate the delivered result, it makes sense to compare it with globally stored DNS entries. We use the DNS Prop­a­ga­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­fig­ured in the system, which deals with the name res­o­lu­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­spec­tive 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­van­ta­geous.

In addition to the pos­si­bil­i­ty of per­son­al­ly as­sign­a­ble DNS in­for­ma­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­lat­ed DNS data to the user. For example, com­peti­tors are blocked, or internet traffic is redi­rect­ed to sites with ad­ver­tise­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­dun­dan­cy 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­o­lu­tion cannot work without a DNS resolver, human-friendly names cannot logically be used.

Free DNS resolvers offer several ad­van­tages. 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 sit­u­a­tions where it makes sense to bypass name res­o­lu­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­re­spond­ing com­bi­na­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­fig­ured like this:

For name res­o­lu­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­at­ed IP address. In this case, the query remains entirely on the local machine. Otherwise, the normal name res­o­lu­tion process takes place via the con­fig­ured 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­pli­ca­tions. 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 pe­ri­od­i­cal­ly check in with a server con­fig­ured 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­o­lu­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­stal­la­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­ces­si­ble 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­vi­ron­ment that is ac­ces­si­ble at the loopback address 127.0.0.1. In the hosts file, we add an entry for the hostname dev.example.com: