What is DNS?

While humans can be identified by names, social security numbers, and biometrics of varying lengths and formats, internet hosts are identified by fixed-format IP addresses. Depending upon the version, IP addresses can either be 32-bit numbers in four decimal blocks or 128-bit characters in eight hexadecimal blocks. For example, an IPv4 address might look like 192.168.1.1, whereas an IPv6 address looks like 2001:0db8:85a3:0000:0000:8a2e:0370:7334.

It’s nearly impossible for humans to remember such multiple long strings of numbers – even remembering a phone number takes more conscious effort than a name or mnemonic phrase does. This is where the Domain Name System (DNS) comes in; it enables humans to locate Internet hosts by a recognizable name.

DNS defined

DNS is an application-layer protocol that translates human-readable host names into IP addresses. 

Often referred to as the "phonebook of the internet", DNS allows websites to stick to memorable and understandable addresses such as www.itpro.com, rather than requiring users to enter the IP address.

Latest Videos From

Watch full video here:

Host names cannot fully specify the host location. For example, .uk suggests the host site is in the UK. But where in the UK? It doesn’t provide a specific location. DNS maps host names to IP addresses to specify host location within the network of networks. 

What is a DNS server?

DNS runs in a client-server model and works on UDP/TCP on port 53. A port is a numbered channel that enables a device to handle multiple types of network traffic at once. It’s like a numbered door that leads to a specific service. Port 53 is a dedicated channel reserved for DNS traffic.

A DNS server is a machine that holds all the records of hostnames-to-IP addresses, which are known as DNS mapping. In practice, most DNS servers run on UNIX/LINUX systems using Berkeley Internet Name Domain (BIND) – a purpose-built software suite with industry-wide adoption, powering roughly eight out of ten DNS servers worldwide. It’s freely available under the Internet Systems Consortium (ISC) license.

Every host machine that wants to reach a domain name relies on a DNS client. Just as DNS servers run on BIND, DNS clients are virtually built into every operating system. A DNS client sends a query to a DNS server, asking for the IP address of a specific hostname. The DNS server looks up the hostname in its stored mapping and returns the corresponding IP address. The exchange between the DNS client and server completes the translation process, as the host machine can use the address to load the website. 

DNS process operates in a distributed hierarchy where records are distributed across multiple DNS servers globally to avoid a single point of failure and also decrease latency. There are three classes of DNS servers:

Root name server: A root name server is at the top of the DNS server hierarchy. It doesn’t store the actual IP address, but knows where to direct the DNS query.

The 13 named root name server authorities (labelled A through M) are operated by 12 organizations, including the Internet Corporation for Assigned Names and Numbers (ICANN), NASA, and the US Department of Defence. These 13 root name server authorities are physically deployed over 1750+ server instances worldwide. This is possible due to Anycast routing, which is a technique that enables multiple servers to share the same IP address. As a result, a DNS query automatically reaches the nearest root name server.

TLD name server: A root name server directs queries to top-level domain (TLD) name servers. The TLD name server sits in the middle of the DNS server hierarchy and manages domains like .com, .org, .net, .gov, .edu, and country-specific domains, including .uk, .de, .fr, .jp, etc.

Similar to root name servers, TLD name servers don’t store the actual IP addresses, but know where to send DNS queries based on purpose, type, and geography.

Authoritative name server: TLD name servers map queries to authoritative name servers, which sit at the bottom of the DNS hierarchy. Authoritative name servers are the single source of truth for the DNS because they hold the IP address. An organization can have its own authoritative name server or get one from a service provider.

DNS recursor: DNS recursors are not a part of the DNS server hierarchy because they are not organized, standardized, and managed by a specific organization. DNS recursors are local servers provided by the internet service provider (ISP) or public DNS, like Google (8.8.8.8) and Cloudflare (1.1.1.1). Each host machine is automatically configured to use a single DNS recursor.

How does DNS work?

DNS lookup is the process of sending DNS messages, whether queries or replies, across the internet with the ultimate goal of translating human-readable domain names into IP addresses. All DNS messages are sent as UDP/TCP datagrams to port 53.  

Application-layer protocols, such as hypertext transfer protocol (HTTP), simple mail transfer protocol (SMTP), and file transfer protocol (FTP), use DNS to translate user hostname requests to IP addresses. 

When a user types a website name in the browser, the browser checks its local cache to fetch the IP address. If the IP address isn’t found there, the request moves on to the operating system, which checks its own DNS cache next. 

DNS caching is the first step that application-layer protocols execute for faster processing and less load on DNS servers. Every cached record has a time-to-live (TTL), which specifies the validity of a cached record. After TTL expires, DNS servers discard cache information because IP addresses are not permanent.

To fetch the IP address, HTTP calls gethostbyname() to invoke the DNS client side on the host machine. DNS client then queries the DNS recursor.

DNS recursor sends a query to the root name server, which directs the query to the TLD name server in the middle layer of the DNS hierarchy. Based on the website name, the TLD name server can be .com, .org, .net, .gov, etc. 

The TLD name server points the query to the authoritative name server. Upon receiving the DNS query, the authoritative name server returns the IP address to the DNS recursor. 

DNS recursor further caches the IP address and returns the reply to the DNS client on the host machine. All of this happens within a few milliseconds to seconds. The browser receives the desired DNS record and uses it to initiate a TCP connection to the destination server, with HTTP operating on port 80 to request and load the website. 

Recursive DNS resolver vs authoritative DNS server

Recursive DNS resolvers and authoritative DNS servers are different parts of the DNS lookup process.

A recursive DNS resolver functions as a “librarian”: it performs iterative search operations on behalf of the host machine to fetch IP addresses in the same way a librarian would search for a book a reader wants in a library

In the final steps of the DNS lookup process, the recursive DNS resolver sends a query to the authoritative DNS server, which holds the IP address. Instead of redirecting the DNS query, the authoritative DNS server finally returns the IP address to the recursive DNS resolver.

What happens when DNS fails?

Slow website loading, redirection to spam sites, or simple on-screen error messages, such as “Server not found”, “DNS server not responding," and “This site can’t be reached,” are common indicators of lookup failure. 

While most people encounter DNS failure while they try to open a website, misconfigurations can affect email delivery too. In such a case, the sender's mail server can’t determine where to deliver the email. The mail can return in the inbox with “DNS lookup failed”, “Domain not found”, or “Mail delivery failed”.  

Some common reasons for DNS lookup failure are listed below. 

• Domain shifted to a new hosting service.
• ISP server misconfiguration.
• Outdated routers.
• Incorrect DNS records: Wrong IP addresses or misspelled domains.
• Incomplete records for IPv6 clients.
• Incorrect DNS settings. 
• High TTL. 
• High latency due to geographical constraints.  

Some common methods to fix DNS failure are to restart or update the router, clear DNS cache, update TCP/IP settings, migrate from legacy devices, or switch to public DNS servers.

While DNS lookups can occasionally fail on their own, hackers can target DNS vulnerabilities through DNS DDoS attacks, cache poisoning, and domain hijacking.

Enterprises can combat DNS attacks by following a failsafe strategy. Configuring a secondary DNS as a backup to reroute traffic during an outage can prevent downtime. Another option is to use cloud DNS services like AWS Route 53 and Cloudflare, which have built-in support for DDoS attacks.