How the Domain Name System Works

This lesson addresses the following questions:

• How is the DNS hierarchy structured?

• How does caching reduce the load on the DNS infrastructure?

• How does the distributed nature of DNS improve robustness?

DNS hierarchy

DNS is not a single server. It is a vast infrastructure comprising name serversname servers can respond to users’ DNS queries organized in a hierarchy.

There are four main types of servers in this hierarchy:

1. DNS resolver: Initiates the query sequence. Resolvers are typically located within the user’s network (e.g., ISP or local network). They often cache results locally to answer future queries, serving as the default server for users.

2. Root-level name servers: The entry point of the hierarchy. These servers direct requests to the appropriate top-level domain (TLD) servers (e.g., .com, .edu). For example, a request for educative.io prompts the root server to return a list of .io TLD servers.

3. Top-level domain (TLD) name servers: These servers maintain the IP addresses of authoritative name servers. They provide the querying party with the location of the organization’s specific servers.

4. Authoritative name servers: The final destination. These servers belong to the organization and provide the actual IP addresses for the requested web or application servers.

Iterative versus recursive query resolution

There are two primary methods for performing a DNS query:

1. Iterative: The local server queries the root, TLD, and authoritative servers sequentially. The local server takes responsibility for navigating the hierarchy.

2. Recursive: The client queries the local server, which then queries the root. The root forwards the request to the next level, and so on. The burden of resolution is passed from server to server.

The illustration below depicts an iterative resolution from the perspective of the local/ISP server:

Note: Iterative queries are typically preferred to reduce the processing load on the central DNS infrastructure.

Caching

Caching is the temporary storage of frequently requested resource records. A record maps a name to a value (like an IP address). Caching significantly reduces response latency and network traffic. It is implemented at various levels, including the browser, operating system, local network, and ISP resolvers.

The slideshow below demonstrates the impact of caching on DNS performance:

Note: Even if a specific domain is not cached, the resolver may still have cached the IP addresses of the TLD or authoritative servers. This allows the resolver to skip the root-level query, speeding up the process.

DNS as a distributed system

DNS is a distributed system that provides several key advantages:

• Resilience: It avoids a single point of failure (SPOF).

• Low latency: Users can receive responses from geographically nearby servers.

• Flexibility: Traffic can be rerouted during maintenance or server failures, ensuring high availability.

There are 13 logical root name servers (labeled A through M), implemented by many physical instances globally and managed by 12 different organizations.

Let’s examine how DNS achieves scalability, reliability, and consistency.

Highly scalable

The hierarchical structure of DNS makes it highly scalable. Roughly 1,000 replicated instances of the 13 root servers are strategically distributed to handle global traffic. The workload is divided: root servers direct traffic, TLD servers filter by domain type, and authoritative servers manage specific records. This division of labor enables the system to efficiently manage immense traffic volumes.

Reliable

Three main factors contribute to DNS reliability:

1. Caching: Browsers, operating systems, and ISP resolvers maintain caches of frequently visited sites. If a DNS server goes down, cached records can still resolve queries.

2. Server replication: DNS servers are replicated globally. This redundancy ensures that if one instance fails, others can handle the load.

3. Protocol: DNS primarily uses UDPUDP does not maintain a connection to send/receive application data.. UDP is connectionless and fast, reducing latency compared to TCP’s three-way handshake. If a query fails, the client simply retransmits the request, often to a different server, ensuring resilience.

Consistent

DNS prioritizes high performance over strong consistency. It employs eventual consistency, meaning updates to records propagate lazily across the hierarchy. This propagation can take anywhere from a few seconds to several days, depending on the infrastructure and the specific record.

Caching also impacts consistency. If an organization updates a record on its authoritative server, other resolvers may still serve the old, cached version. To manage this, every record includes a time-to-live (TTL)TTL refers to the amount of time a record can be cached by the querying party. TTL values are reported in the units of seconds., which dictates when the cache must expire and refresh the data.

Test it out

Run the following commands in the terminal to observe DNS resolution in action:

1. nslookup www.google.com

2. dig www.google.com

The following slides highlight key aspects of the nslookup and dig outputs.

Let’s analyze the output:

The nslookup output

• Non-authoritative answer: This indicates the response came from a cache (such as your ISP or university resolver) rather than directly from Google’s authoritative name servers.

• IP order: If you run the command multiple times, the list of IP addresses may change order. This is due to DNS Round robin, a technique used to load balance traffic across multiple servers.

The dig output

• Query time: The time taken to receive a response from the DNS server.

• ANSWER SECTION TTL: The value 300 represents the Time-To-Live in seconds. This means the resolver will cache this record for 5 minutes ($\frac{300 \ \text{sec}}{60}$) before refreshing it.

Note: Try testing different services to observe their TTL values and query times using the terminal above.