Introduction to DNS

What is DNS (Domain Name System)?

DNS, or Domain Name System, is a system used to translate human-readable domain names (e.g., www.designgurus.com) into IP addresses (e.g., 198.47.25.1) that computers can understand. This translation process is crucial because computers and networking devices rely on IP addresses to identify and communicate with each other on the internet. In simple terms, DNS acts like a phonebook for the internet, allowing users to access websites using easy-to-remember domain names instead of having to memorize numeric IP addresses.

Purpose and Importance of DNS

The primary purpose of DNS is to make it easier for people to access websites and other online resources. By providing a human-readable naming system for computers and other devices connected to the internet, DNS enables users to navigate the internet using familiar and intuitive domain names.

DNS is essential for the smooth functioning of the internet. Some of its key benefits include:

• User-friendliness: Domain names are easier to remember and type than IP addresses, which are long strings of numbers.
• Scalability: DNS is a distributed and hierarchical system, allowing it to handle the ever-growing number of domain names and IP addresses on the internet.
• Flexibility: DNS allows websites to change their IP addresses without affecting users. When a website's IP address changes, the DNS records are updated, and users can continue accessing the site using the same domain name.
• Load balancing: DNS can distribute user requests across multiple servers, improving the performance and reliability of websites.

DNS Components and Terminology

1. Domain names, TLDs (Top-Level Domains), and subdomains

• Domain names: A domain name is a human-readable address used to access a website or other resources on the internet. It consists of a series of character strings separated by dots, such as www.example.com. Domain names are easier to remember and use than IP addresses.

• TLDs (Top-Level Domains): A top-level domain (TLD) is the rightmost part of a domain name, such as ".com" in www.example.com. TLDs are managed by various organizations and can be divided into two categories: generic TLDs (gTLDs), like .com, .org, or .net, and country-code TLDs (ccTLDs), which represent specific countries or territories, like .us for the United States or .uk for the United Kingdom.

• Subdomains: A subdomain is a subdivision of a domain name, allowing the creation of separate sections or areas within a website. Subdomains appear to the left of the main domain name, such as blog.example.com, where "blog" is the subdomain of example.com.

2. DNS servers: Root, TLD, and Authoritative Name Servers

• Root servers: Root servers are the highest level of DNS servers and are responsible for directing queries to the appropriate TLD servers. There are 13 root server clusters worldwide, managed by various organizations, each having multiple servers for redundancy and reliability.

• TLD servers: TLD servers store information about domain names within their specific TLD. When they receive a query, they direct it to the appropriate authoritative name server responsible for that domain.

• Authoritative name servers: These servers hold the actual DNS records for a domain, including its IP address and other information. They provide the final answer to DNS queries, allowing users to access the desired website or resource.

3. DNS resolvers

A DNS resolver is any component (software or hardware) responsible for translating a human-friendly domain name (like example.com) into the IP address that the computer needs to connect to (such as 93.184.216.34).

When you type a website address into your browser or click a link, your system relies on DNS resolvers to figure out the correct IP address. There are several types of DNS resolvers, each serving different roles in the DNS lookup process.

The DNS Lookup Process in Brief

In one line: your device’s stub resolver asks a recursive resolver (often your ISP’s or a public DNS like Google’s 8.8.8.8), which answers from its cache when it can and otherwise walks the hierarchy — root, then TLD, then authoritative — on your behalf. The full step-by-step walk, with round-trip counts and who recurses at each hop, is traced in "A concrete walk" further down this page.

1. Stub Resolver

A stub resolver is the minimal DNS client software running on your device (laptop, smartphone, IoT gadget, etc.) that starts the DNS lookup process. It typically does not perform the full DNS query process by itself.

How It Works

• The stub resolver knows one or more DNS servers to send queries to. These DNS servers are often configured automatically (for example, via DHCP on your home router) or manually by users (e.g., configuring 8.8.8.8 for Google DNS).
• When your device needs to resolve a domain name, the stub resolver sends a request to the configured DNS server and waits for the response.
• The stub resolver takes the response (the IP address or an error) and hands it back to the application (like a web browser).

Example

• On Windows or macOS, you can see your DNS server addresses in your network settings. These addresses often point to your router (which might act as a basic DNS forwarder) or directly to an ISP-provided DNS server.
• If you have manually configured 8.8.8.8 (Google Public DNS) or 1.1.1.1 (Cloudflare DNS), your computer’s stub resolver sends all DNS queries to Google or Cloudflare, respectively.

2. Recursive Resolver

A recursive resolver is a DNS server that actively performs the DNS query process on behalf of the client. It hunts down the IP address by querying multiple DNS servers until it gets the final answer.

How It Works

1. The recursive resolver receives a request from a stub resolver (or another forwarder).
2. It first checks its local cache to see if the requested domain’s IP address is stored there.
   • If found, it returns the cached answer immediately.
3. If the record is not cached, the resolver queries the root DNS servers to learn which TLD server (e.g., .com, .org) to query next.
4. It then queries the relevant TLD server to find the authoritative DNS server for the specific domain.
5. Finally, it queries the authoritative server to obtain the required DNS records (e.g., the A record for IPv4).
6. The resolved IP is cached for future requests and returned to the stub resolver.

Example

• ISP DNS Resolver: Most internet service providers run their own recursive DNS resolvers that their customers use by default.
• Public DNS Resolver: Google Public DNS (8.8.8.8), Cloudflare DNS (1.1.1.1), and OpenDNS (208.67.222.222) are common public recursive resolvers.

3. Caching-Only Resolver

A caching-only resolver is a type of DNS server whose primary function is to cache DNS query results and reuse them to speed up subsequent lookups. It does not host any DNS zones (i.e., it is not authoritative for any domain) and typically performs recursive lookups on behalf of clients.

How It Works

• Like a recursive resolver, a caching-only resolver forwards queries to other DNS servers if the record is not already in its cache.
• Once it obtains the result, it stores (caches) the DNS records for the duration specified by their TTL (Time to Live).
• Subsequent queries for the same domain within the TTL period are served faster from the cache, reducing the need for external lookups.

Example

• Many home routers or DNS forwarders act as caching-only resolvers. Once a family member’s device visits example.com, the router caches the IP for that domain. If another device requests example.com soon after, it is resolved almost instantly from the router’s cache.

4. Forwarder

A forwarder is a DNS server that forwards all queries (or queries that it cannot resolve locally) to another DNS server instead of performing the complete recursive resolution process itself.

How It Works

• A DNS server is configured to send queries to an upstream DNS server, often a well-known public DNS or an ISP DNS.
• The forwarder may still maintain a local cache to speed up DNS resolution for repeated queries.
• This setup is common in corporate networks to manage and log DNS queries centrally or apply custom policies (e.g., content filtering).

Example

• A small business might have a local DNS server that forwards any external domain queries to their ISP’s DNS servers or Google DNS. This helps centralize DNS settings and possibly implement local domain resolutions (like intranet.local) without handling the complexity of a full recursive resolver setup.

5. Iterative (Non-Recursive) Resolver

Sometimes called a non-recursive resolver, an iterative resolver typically gives back partial results or referrals, instructing the client to continue the resolution process on its own.

How It Works

• If a client asks this resolver for a record, the resolver either:
  • Returns the answer if it is authoritative or has it cached, or
  • Returns a referral with the address of another DNS server (for instance, the root or TLD server), prompting the client to “try there next.”

This type is less common for end-user devices; it is often used by authoritative DNS servers to direct queries up or down the DNS hierarchy.

Example

• An authoritative DNS server for example.com typically returns referrals for subdomains it does not know. If you ask it about sub.example.com but that subdomain is handled by a different name server, it might respond with the details of that other name server rather than performing the recursion on your behalf.

Visualizing the DNS Resolution Chain

Below is a simplified chart showing the typical path of a DNS query:

User's Device (Stub Resolver)
     |
     v
Recursive Resolver (Often ISP/ Public)
     |
     v
  Root Server
     |
     v
 TLD Server (.com, .net, etc.)
     |
     v
 Authoritative Server (example.com)
     |
     v
   IP Address

• Stub resolver: Passes the domain name request to the recursive resolver.
• Recursive resolver: Takes on the hard work of querying each layer (root, TLD, authoritative) if it doesn’t have the answer cached.
• Caching: Each resolver may cache responses to speed up future queries.

Putting It All Together

1. Stub Resolver on your device:

   • Minimal functionality—just sends the query to a DNS server.

2. Recursive Resolver (may also be a Caching-Only Resolver):

   • Receives queries from stub resolvers.
   • Looks up (recursively) the chain of DNS servers if not cached.
   • Caches the response for future requests.

3. Forwarder:

   • A DNS server configured to pass queries on to another resolver rather than doing the full lookup.
   • Can also cache responses.

4. Iterative (Non-Recursive) Resolver:

   • Responds with direct answers if known or references to other DNS servers (referrals), but doesn’t do recursion.

Real-World Example Scenario

1. Your Laptop (Stub Resolver) is set to use 8.8.8.8 (Google DNS).
2. You type www.example.com into your browser.
3. The stub resolver on your laptop sends the DNS query to 8.8.8.8 (a Public Recursive Resolver).
4. Google DNS checks its cache:
   • If www.example.com is cached, it returns the IP right away.
   • If not, it queries the root server, then .com TLD server, then the example.com authoritative server in turn.
5. Once found, the IP address is cached in Google’s DNS servers and returned to your laptop’s stub resolver.
6. Your laptop connects to the returned IP address, and the website loads.

Why DNS is a hierarchy — and why that matters

DNS is not hierarchical because someone drew a tree. Three forces push the design toward delegation:

• Delegation of authority. The root delegates .com to the TLD operator, who delegates example.com to the domain owner. No single organization has to edit every record on the internet.
• Bounded knowledge per node. A root server only knows the TLD servers; a .com server only knows the authoritative name servers for domains in .com. Each tier knows just enough to point one level down, so the system scales without a central database of billions of hostnames.
• Caching collapses read load. Every resolver along the path caches answers for the duration of the record's TTL. A busy recursive resolver answers 80–90% of queries from its own cache, which is why the root servers can survive the entire internet's query load.

These three properties are inseparable: delegation lets different people run different parts, bounded knowledge keeps each server small, and caching keeps the root servers from melting.

A concrete walk: resolving www.example.com on a cold cache

Here is the exact chain of messages, with round-trip counts and who does the recursion at each step:

1. Stub resolver → recursive resolver (1 round trip): "A? www.example.com" (recursive query — the stub expects a final answer). The recursive resolver holds the query open while it does the work.
2. Recursive resolver → root server (1 round trip): root returns a referral to the .com TLD servers (iterative — the server returns a referral, never recursing).
3. Recursive resolver → .com TLD server (1 round trip): TLD returns a referral to the authoritative name servers for example.com (iterative — a referral again).
4. Recursive resolver → authoritative server (1 round trip): the authoritative server returns the A record (e.g., 93.184.216.34) and a TTL (iterative — but this server holds the answer, so the referral chain ends here).
5. Recursive resolver → stub resolver: the held-open query finally returns the answer; the stub and OS cache it for the TTL.

The recursive resolver hides the iteration from the client; the root and TLD servers never recurse — they only point the resolver to the next authority.

That is four network round trips on a fully cold cache. On a warm cache the same query is often answered in about a millisecond from the local resolver. Short TTLs let you change infrastructure quickly but multiply the load on authoritative servers; long TTLs reduce load but slow propagation.

What can go wrong — the operability view

• NXDOMAIN means the authoritative server says "this name does not exist." It is cached negatively (using the SOA minimum TTL), so a typo or a record that was just deleted can keep failing for clients until that negative cache expires.
• SERVFAIL usually means the authoritative server could not be reached or the response could not be validated (for example, DNSSEC signature expiry). Clients should retry against another resolver or name server.
• Stale cache. If you repoint an A record, every resolver and client that already cached the old address keeps using it until the TTL expires. Failover by DNS alone is therefore detection time + remaining TTL + client-side cache time, not instantaneous. Concretely: TTL 300s, health checks detect the dead IP in 30s and pull the record — but a resolver that cached the record 50s before the failure keeps serving the stale set until its TTL runs out at t = 250s, so that resolver's clients recover roughly 4.2 minutes after the crash, and a browser that pinned the answer in its own ~60s cache waits longer still. The full second-by-second timeline is worked on DNS Load Balancing and High Availability.
• Cache poisoning. Because classic DNS uses UDP and no authentication, an attacker who guesses the query ID and source port can inject a forged answer. DNSSEC closes this by cryptographically signing the chain of trust from the root downward; DNS-over-HTTPS/TLS only encrypts the stub-to-resolver hop.
• Resolver failure. If your only configured recursive resolver is down, every name lookup stalls. Operating systems usually allow at least two resolver addresses for this reason.

Choosing a resolver

DNS "load balancing": promise and limits

DNS can return multiple A records (round-robin) or different answers based on the resolver's location (GeoDNS/GSLB). What it cannot do is see server load, health, or per-connection state. DNS steering is therefore coarse, TTL-bound regional steering, not a replacement for a layer-4/layer-7 load balancer with health checks. Use DNS to pick a region; use a real load balancer inside the region to distribute individual requests.

DNS record-type table

TTL and cache behavior

The TTL (Time To Live) on a DNS record tells resolvers how long they may keep the answer before asking again. TTL is a trade-off:

• Short TTL (seconds to minutes): Failover is fast, but authoritative servers see more load and clients experience slightly higher latency.
• Long TTL (hours to days): Reduces load and improves latency, but changes propagate slowly and failed IPs stay cached.

When you change an A record, every resolver that already cached the old value continues serving it until the TTL expires. OS stub resolvers, browsers, and middleware caches may also keep their own copies, so real propagation is TTL plus whatever extra caching layers exist.

Interview traps

• "DNS failover is instant once I change the A record." It is not: cached answers, OS/browser caches, and open connections all outlive the TTL.
• "DNS-over-HTTPS stops cache poisoning." It does not: it only encrypts the stub-to-resolver leg. Poisons target the resolver-to-authoritative hop; use DNSSEC for integrity.
• "Round-robin DNS balances load evenly." It does not: one large resolver caches a single ordering and pins thousands of users to one IP for the TTL.

Interactive scenario

Play with the dns simulator and predict the outcome before each step.