How DNS works

Let’s introduce DNS, its essential operation, and how a DNS query works.

This post is the first part of a series of posts detailing how the DNS protocol works.

Motivation for using DNS 

Names are more manageable for humans to write. Therefore, we can learn to remember website names instead of memorizing various IP numbers.

IPs can change, but if you have a name, you can link that name to your new IP. In the figure below, we are assuming that the first WEB server has failed.

Figure: ServerWEB is on the computer’s IP :(203.0.113.1)

Now let’s assume that the computer (203.0.113.1) crashed or shut down.

However, the user can access the content after we bind the name to the new IP.

Now let’s point ServerWEB to the computer (203.0.113.5)

We can have several IPs associated with the same name, creating a load balance. 

In the figure above, the first user goes to the computer (203.0.113.1). The second user goes to computer (203.0.113.2) and the third user goes to computer (203.0.113.3).

The DNS will create a load balance as new users access the same name. This behavior occurs because DNS divides access to different WEB servers.

How DNS Began

“On the ARPANET the hosts.txt file was used. This file contained the list of hostnames and their IP addresses. This file was used daily to identify the IP of hosts by name. 

Problem using hosts file 

If we are on a small network, this strategy would be viable.

For example, we could have a single hosts.txt file stored on a server, and each user would use this file for their queries.

However, on large networks, using the hosts.txt file causes some problems. Among the problems we have: 

• Inconsistency in updating names and IPs. Consequently, this inconsistency would cause problems in standardizing the access of names and IPs.  
• The hosts.txt file is too large. In addition, hosts.txt files would slow down name lookup and take up more storage memory.
• Also, if we were to centralize the hosts.txt file on a single server, we would have resource overload issues and less fault tolerance. 

Lab with the hosts file: We demonstrate how to edit the hosts file on Linux, Windows and Mac and do a hands-on lab with the hosts file (Click here) . 

DNS 

Created to solve problems related to the translation of names and IPs, the DNS (Domain Name System) was created in 1983. 

The DNS was created to have a hierarchical structure and a geographically distributed database. Therefore, DNS would solve the problems mentioned earlier.

DNS can be used to map a name in  IPs or to know the name associated with an IP (Reverse Lookup). 

Currently, DNS is also defined in RFCs: 1034, 1035, 2181. 

How DNS works 

DNS is used in the following way: to map a name to an IP address, an application program calls a library procedure (usually gethostbyname or something equivalent) and passes the name as a parameter.

After that the query of names is forwarded to the local DNS, as in the figure below.

Note. The name resolver process can be called a resover stub. 

DNS maps a name to an IP address using procedure calls such as “gethostbyname”.  

It is worth mentioning that the query for this mapping is made for a local name resolver (the local DNS).

This local name resolver initiates a recursive lookup using multiple DNS resolvers.

Recursive DNS query example

We can use as an example a browser accessing a page name for the first time. 

Initially, the browser would forward the name resolution request to the process responsible for name resolution. 

The host would then forward the request to the host’s local or default DNS server. 

The host queries its local DNS and waits for the response. 

After that, the local DNS checks if it has cached the name that answers the query. 

If the default/local DNS knows how to resolve that name, it will return the IP. 

If the local DNS does not have the name cached, it makes recursive queries for each hierarchical piece of the name being fetched. 

After the recursive query is finished, the local resolver returns the answer, which is usually an IP.

Consequently, the host can hand over the IP address to the requesting application, and that application can perform access using the IP. 

Note. Over time, DNS queries were mostly UDP queries. However, DNS can also perform queries using the TCP protocol. 

Why does local DNS do recursive query? 

The local DNS server does recursive queries because it only serves hosts in your domain. This way, the recursive query does not overload the local DNS. 

Only local DNS does recursive query? 

To answer this question, let’s investigate how the other DNSs answer the questions. Root DNS servers do not work recursively. Instead, these servers point to other DNS servers that can respond with part of the name query. With this information, the local DNS will ask for the DNS that the root DNS server indicated.

Why doesn’t the root server do the recursive query? 

The truth is that the recursive query causes a lot of overhead for the running server. In this way, the root DNS server prefers to pass the query interactively and respond by telling the local DNS who to query to complete its name discovery. 

What does local DNS do with incoming queries? 

Query responses are cached, and this includes partial query responses. So, as the recursive query returns partial information until the entire domain is reached, the local DNS cache will also store partial information.

By caching query responses, local DNS allows new queries for the same domain to be answered without a new query. In this way, the cache promotes more excellent performance since part of the queries in a company tends to be repeated.

How long aname should be cached in DNS? 

The answer to this question depends on how volatile the domain information is, which means that domains that vary less frequently may spend longer in the local DNS cache.

On the contrary, domains with high volatility in mapping names to IPs should have a short lifetime in local DNS caches.

What happens when a DNS query is not answered? 

The local DNS makes a request and waits for a while. So if it doesn’t respond, the local DNS will try another DNS server that can answer your query.

It is very common to see the presence of secondary DNS in some systems.

For example, a host can use a secondary DNS to respond to requests when the primary DNS fails or is overloaded.

Note. Using a secondary DNS on a host can avoid problems with no internet connection. Often our internet provider’s DNS needs to be fixed or even fails.

This failure can lead us to the wrong conclusion that we need Internet access. However, we are left with no access to a DNS server that can service our queries.

How to avoid being without access to the Internet due to a DNS failure at the provider? 

One of the ways to avoid being without internet access due to a failure in the provider’s DNS server is to add a second DNS in your host’s network configuration.

In this case, we can use public DNS like google’s “8.8.8.8”. If your provider’s DNS fails, your host will use the second DNS you entered in the settings.

The figure below shows a configuration where we use a secondary DNS from google. In this case, we are using “8.8.8.8” as a secondary. 

What does a DNS query look like? 

We have a transaction ID and the name being queried in the query data. The transaction ID keeps track of the DNS request and response transaction.

The recursive query most often uses a minimal Query Name (QNAME). This way, the local DNS can send a portion of the query to the name server that serves only that portion of the query, such as an authoritative name server.

Let’s assume that our local DNS server will search on the name www.simplificandoredes.com . In this case, our DNS would send the query to an authorized DNS server, requesting just simplifyingredes.com.

It would only submit part of the Fully Qualified Domain Name (FQDN). This way of submitting queries helps with security.  

Initially, DNS used the UDP protocol and port 53 to handle query requests. However, over the years, denial of service and cache poisoning attacks were developed that exploited a vulnerability in the name request.

Furthermore, using UDP was initially motivated to ensure greater speed in meeting DNS requests. However, the current internet access speed allows DNS queries to use TCP without significantly affecting the speed of response to name requests.

Why does TCP cause a slower DNS response? 

The slowness caused by TCP is due to the beginning of the TCP connection that uses a three way handshake to make the connection and then send the data.

That way, instead of sending just one request, as it would with UDP, the DNS with TCP will make the 3-way handshake, and only after that will the DNS query answer be given.

Is it worth using DNS with TCP? 

TCP allows the use of more secure protocols like DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH), then the answer is yes.

See more :

Build Your Own DNS Server: A Step-by-Step Guide using BIND9

How to edit hosts file

Install Zabbix on Ubuntu

Installing servers in Docker

Virtual Router with OpenWRT

Configure Load Balance with PfSense

• Tutorial how to Install and configure VNC on Ubuntu
• Build Your Own DNS Server: A Step-by-Step Guide using BIND9
• Tutorial for SSH Public Key Authentication
• Socket UDP Python Chat
• Socket TCP Python make a chat