Skip to main content

8.2 Domain Name System (DNS): Hierarchical Namespaces & Resolution

Back to Computer Networks Notes
📚Module 08: Application Layer ProtocolsTopic 8.2⏱️16 min read
🎯High-Yield For:Semester Exams (All Universities) • Placement Technical Rounds • Engineering Foundations

💡 Core Intuition: The Multi-Tier Global Phone Directory​

🍳 The Everyday Analogy: The International Postal Directory​

Imagine wanting to write a letter to a person named "Abhay Ojha" who lives in New Delhi, India, but you do not know his street address:

  1. The Global Index Desk (Root): You ask the international postal directory. The desk operator says: "I don't know Abhay's street, but here is the contact info for the India National Postal Office (.in)."
  2. The Country Office (TLD): You contact the India Postal Office. The operator responds: "I don't know Abhay, but here is the address for the Delhi Municipal Postal Registry (delhi.in)."
  3. The Neighborhood Post Office (Authoritative): You contact the Delhi Municipal Registry. The clerk checks their local ledger and says: "Yes! Abhay lives at House #42, Block B, Connaught Place."

💻 Bridging to Computer Science​

In computer networks:

  • Humans identify servers using memorable mnemonic hostnames (such as www.binarydose.com or mail.google.com).
  • Network routers and IP layer switches identify endpoints using numerical IP addresses (such as 142.250.190.46 or 2607:f8b0:4005:808::200e).
  • The Domain Name System (DNS) is the distributed, hierarchical database that maps human-friendly hostnames to machine-routable IP addresses. If DNS were centralized into a single database server, it would fail catastrophically due to single-point failure, massive query volume, extreme network latency, and impossible maintenance overhead.
📑Table of Contents

🌳 The Hierarchical DNS Namespace​

The DNS namespace is organized as an inverted tree with the Root Zone (.) at the top.

The Hierarchical DNS Server Hierarchy

Distributed tree structure partitioning name resolution authority across independent administrative tiers

Tier 1: Apex

Root Name Servers (Root Zone '.')

🌐

13 logical IP identities (a.root-servers.net to m.root-servers.net), replicated globally across 1,500+ Anycast instances.

Delegates to Top-Level DomainsManaged by ICANN / IANAReturns TLD referrals
↓Delegates to TLD Servers
Tier 2: TLD

Top-Level Domain (TLD) Servers

🏛️

Maintains records for generic TLDs (.com, .org, .net, .edu) and country-code ccTLDs (.in, .uk, .jp).

Verisign (.com, .net)PIR (.org)National Registries (.in, .de)Returns Authoritative referrals
↓Delegates to Authoritative Name Servers
Tier 3: Authority

Authoritative Name Servers

🏢

Maintained by organizations or DNS hosting providers (Cloudflare, AWS Route 53, Google Cloud DNS).

Contains actual hostname-to-IP mappingsZone Files with A, AAAA, MX, CNAMEAuthoritative Answer (AA flag set)
↓Supplies Final IP Mapping to Resolver
Edge: Resolver

Local Recursive Resolvers

⚡

Operated by ISPs, enterprises, or public providers (Google 8.8.8.8, Cloudflare 1.1.1.1). Performs iterative queries on behalf of clients.

Aggressive Caching with TTLPrefetches & minimizes WAN latencyShields root/TLD servers from query floods

Anatomy of a Fully Qualified Domain Name (FQDN)​

Consider the FQDN: blog.binarydose.com.

  • Trailing Dot (.): Represents the invisible DNS root.
  • Top-Level Domain (com): The generic TLD managed by registry operators (e.g. Verisign).
  • Second-Level Domain (binarydose): The domain registered by the organization.
  • Subdomain / Hostname (blog): The specific service endpoint defined by the domain administrator.

🔄 Name Resolution Paradigms: Recursive vs Iterative Queries​

When an application calls the resolver library (e.g. getaddrinfo() in C/Linux), two fundamentally different query patterns can resolve the name.

1. Recursive Query​

In a Recursive Query, the client places the full burden of resolution on the queried server. The queried server must return either the requested resource record or an explicit error ("Name Does Not Exist" / NXDOMAIN). It cannot return a referral to another server.

  • The query from the Client Host →\to Local Recursive Resolver is almost always Recursive.

2. Iterative Query​

In an Iterative Query, if the queried server does not possess the requested mapping, it replies with a referral: the IP address of the next DNS server down the hierarchy that the requester should contact next. The requester must then issue a fresh query to that referred server.

  • The queries from the Local Recursive Resolver →\to Root, TLD, and Authoritative Servers are strictly Iterative.
Why are Root Servers Never Queried Recursively?

If billions of clients sent recursive queries directly to the 13 Root Name Servers, the root infrastructure would have to hold millions of open socket connections and query state buffers in memory simultaneously, causing catastrophic denial of service. By operating strictly iteratively, root servers answer with small referral packets in a fraction of a millisecond and immediately drop all state.

🪜 The End-to-End DNS Resolution Sequence​

The diagram below illustrates the exact sequence when a client requests www.binarydose.com with a cold local cache:

Space-Time Protocol Ladder
Step 1 of 8

Iterative DNS Name Resolution Sequence

Space-time message exchange between client host, local recursive resolver, root, TLD, and authoritative servers

💡Click or hover any packet flight arrow, timer event, or step button to inspect protocol mechanics in real time
TIME (t)+∞
💻End User
Client Host
Lifeline Rail (t ↓)
⚡ISP / 8.8.8.8
Local Resolver
Lifeline Rail (t ↓)
🌐ICANN Anycast
Root Server (.)
Lifeline Rail (t ↓)
🏛️Verisign TLD
TLD Server (.com)
Lifeline Rail (t ↓)
🏢ns1.binarydose
Authoritative NS
Lifeline Rail (t ↓)
11. Recursive Query(A? www.binarydose.com)
22. Iterative Query(A? www.binarydose.com)
33. Referral to TLD(NS .com -> TLD IP)
44. Iterative Query(A? www.binarydose.com)
55. Referral to Auth NS(NS binarydose.com -> ns1 IP)
66. Iterative Query(A? www.binarydose.com)
77. Authoritative Answer(A = 104.21.55.2 (TTL=300s))
88. Final DNS Response(IP: 104.21.55.2)
Step 1 of 8client ➔ resolver✅ Delivered Successfully1. Recursive Query

Client checks local OS DNS cache and hosts file. On cache miss, sends recursive query to Local Resolver.

📋 DNS Resource Records (RR) Architecture​

The distributed database stores entries called Resource Records (RRs). A resource record is a 4-tuple:

(Name,  Value,  Type,  TTL)\mathbf{\big(\text{Name}, \; \text{Value}, \; \text{Type}, \; \text{TTL}\big)}

  • TTL (Time to Live): The duration (in seconds) that caching resolvers are permitted to hold the record before discarding it.

Standard Resource Record Types​

RR TypeMeaningFormat (Name, Value)Practical Real-World Purpose
AIPv4 Address(hostname, IPv4_address)Maps a hostname to a 32-bit IPv4 address (e.g. binarydose.com -> 104.21.55.2).
AAAAIPv6 Address(hostname, IPv6_address)Maps a hostname to a 128-bit IPv6 address (e.g. binarydose.com -> 2606:4700::1).
CNAMECanonical Name(alias_name, canonical_name)Maps an alias hostname to the real canonical name (e.g. www.binarydose.com -> binarydose.com).
NSName Server(domain, nameserver_hostname)Delegates a domain zone to an authoritative name server (e.g. binarydose.com -> ns1.cloudflare.com).
MXMail Exchanger(domain, mail_server_hostname, priority)Specifies SMTP mail server for the domain, with an integer priority value where lower means preferred.
PTRPointer Record(reversed_ip.in-addr.arpa, hostname)Reverse DNS lookup: maps an IP address back to its associated hostname.
TXTText Record(domain, arbitrary_text_string)Holds machine-readable validation text: SPF, DKIM, and DMARC anti-spam policies.
SOAStart of Authority(zone, primary_ns, admin_email, serial_no, refresh, retry, expire, min_ttl)Authoritative header of a zone file; controls zone transfer frequency and negative caching TTL.

🔌 Transport Dynamics: UDP Port 53 vs TCP Port 53​

DNS is one of the few standard protocols that operates over both UDP and TCP on Port 53.

UDP Port 53 vs TCP Port 53 in DNS

Contrasting lightweight connectionless queries against reliable bulk data streams

Default Query Mode

UDP Port 53 (Standard Queries)

⚡
Dominant Architecture / DomainClient Lookups, Resolver Forwarding
  • •Zero handshake latency: client sends a single UDP datagram and waits for reply.
  • •Historically capped at 512 bytes payload per RFC 1035.
  • •Extended to 4096 bytes via EDNS0 (Extension Mechanisms for DNS - RFC 6891).
  • •If response exceeds buffer, server sets TC (Truncation) bit, forcing TCP fallback.
"Ultra-fast single-round-trip lookups minimizing web page loading delay."
Reliable Stream Mode

TCP Port 53 (Zone Transfers & Large Data)

🛡️
Dominant Architecture / DomainAXFR / IXFR, DNSSEC Overflows
  • •Primary-to-Secondary DNS Zone Transfers (AXFR - full transfer, IXFR - incremental).
  • •Responses exceeding UDP/EDNS0 limits where TC=1 flag was returned.
  • •Large DNSSEC responses carrying multiple cryptographic keys and RRSIG signatures.
  • •Guarantees reliable byte-stream transmission and eliminates packet loss fragmentation.
"Reliable bulk replication maintaining zone consistency across replica servers."

🗄️ DNS Caching, TTL Dynamics & Negative Caching​

To prevent global root and TLD servers from buckling under query traffic, DNS employs aggressive multi-layer caching:

  1. Browser Cache: Chrome/Firefox caches resolved IPs for 60 seconds.
  2. OS Resolver Cache: Windows (ipconfig /displaydns) and macOS mDNSResponder cache records according to TTL.
  3. Local Resolver Cache: ISP and corporate resolvers cache both the final answer (A record) and intermediate referrals (NS records for .com and binarydose.com).

Negative Caching (RFC 2308)​

When a queried hostname does not exist, the authoritative nameserver replies with NXDOMAIN. Resolvers cache this negative result for the duration specified in the zone's SOA Minimum TTL field, preventing malicious or buggy clients from bombarding the DNS hierarchy with repeated lookups for nonexistent domains.

🛡️ DNS Security: Cache Poisoning & DNSSEC​

Because standard DNS queries use unauthenticated, plaintext UDP datagrams, they are vulnerable to interception and spoofing.

The Kaminsky DNS Cache Poisoning Attack (2008)​

  1. In standard DNS, a resolver identifies a legitimate reply by matching a 16-bit Transaction ID (TXID) and the destination UDP Port Number.
  2. A 16-bit TXID offers only 216=65,5362^{16} = 65,536 combinations.
  3. An attacker queries a resolver for random123.victim.com. While the resolver queries the authoritative server, the attacker floods the resolver with thousands of forged UDP replies guessing the TXID, claiming victim.com resolves to the attacker's IP.
  4. Remedy: Source Port Randomization (using all 16 bits of ephemeral port plus 16 bits of TXID =232≈4.3 billion= 2^{32} \approx 4.3\text{ billion} combinations).

DNSSEC: Cryptographic Authenticity (RFC 4033)​

Domain Name System Security Extensions (DNSSEC) does not encrypt DNS queries (data remains visible). Instead, it provides origin authentication and data integrity through digital signatures:

  • RRSIG (Resource Record Signature): Cryptographic signature accompanying every record set.
  • DNSKEY: Public key used to verify RRSIG records.
  • DS (Delegation Signer): Hash of the child zone's public key stored in the parent zone, establishing an unbroken Chain of Trust from the Root Key Signing Key down to the leaf domain.

💻 Practical Inspection: Command-Line DNS Tools​

1. Dig: Tracing Full Iterative Resolution​

# Trace the full resolution path from root servers down to authoritative
dig +trace www.google.com

2. Inspecting MX & TXT Records​

# Query mail exchanger records
dig google.com MX +noall +answer

# Query anti-spam TXT records (SPF / DMARC)
dig google.com TXT +noall +answer

🏭 Real-World Production Context: BGP Anycast DNS, Cloudflare 1.1.1.1 & Encrypted DNS (DoH/DoT)​

1. BGP Anycast Routing for Global DNS Resilience​

How do public DNS providers like Cloudflare (1.1.1.1) and Google (8.8.8.8) provide single-digit millisecond latency worldwide on a single IP address?

  • They deploy BGP Anycast: hundreds of physical data centers across over 100 countries announce the exact same IP prefix (1.1.1.1/32) into the global BGP routing table.
  • Internet routing protocols naturally steer each user's packet to the topographically closest data center PoP (Point of Presence).
  • If a DDoS attack hits a specific data center, or an undersea cable is cut, the BGP router stops advertising the prefix, and global traffic automatically re-routes to the next closest healthy data center within seconds without dropping service.

2. Encrypted DNS: DNS-over-HTTPS (DoH) & DNS-over-TLS (DoT)​

Standard port 53 DNS is transmitted as plaintext UDP datagrams. ISPs, coffee shop Wi-Fi sniffers, and nation-state censors can monitor every website an individual visits or inject forged responses:

  • DNS over TLS (DoT / RFC 7858): Wraps raw DNS queries inside a secure TLS tunnel on dedicated TCP port 853.
  • DNS over HTTPS (DoH / RFC 8484): Transmits binary DNS wireformat requests (application/dns-message) encapsulated inside HTTP/2 or HTTP/3 POST/GET requests over TCP/UDP port 443.
  • Because DoH blends invisibly with normal HTTPS web browsing traffic, network eavesdroppers and firewalls cannot inspect or block DNS lookups without blocking all HTTPS traffic to the provider.

3. GeoDNS & Dynamic Traffic Steering in Modern CDNs​

Companies like Netflix, Apple, and GitHub utilize GeoDNS (Latency-Based DNS Routing):

  • When a recursive resolver queries an authoritative nameserver, the authoritative server extracts the resolver's IP (or the client's subnet via EDNS Client Subnet - ECS / RFC 7871).
  • Instead of returning a static IP, the DNS server consults real-time network topology databases and returns the IP address of the edge cache server with the lowest network latency to that specific ISP.

📐 Numerical Applications & Worked Examples​

Example 1: End-to-End DNS Resolution Latency (Cold Cache vs Warm Cache)​

Problem Statement: A client browser requests a web page from www.example.com.

  • Round-Trip Time (RTT) between client and Local DNS Resolver (LDNS): RTT0=4 ms\text{RTT}_0 = 4\text{ ms}.
  • RTT between LDNS and Root DNS server: RTTroot=25 ms\text{RTT}_{\text{root}} = 25\text{ ms}.
  • RTT between LDNS and .com TLD server: RTTTLD=20 ms\text{RTT}_{\text{TLD}} = 20\text{ ms}.
  • RTT between LDNS and example.com Authoritative nameserver: RTTauth=35 ms\text{RTT}_{\text{auth}} = 35\text{ ms}.
  • Assume processing times at all servers are negligible.
  1. Calculate the total latency required to resolve the hostname assuming a completely cold cache (LDNS holds no cached records).
  2. Calculate the resolution latency if the LDNS already has the .com TLD nameserver records cached (warm TLD cache).
  3. Calculate the resolution latency if the LDNS holds an unexpired cache entry for www.example.com.

Step-by-Step Solution:

  1. Cold Cache Iterative Resolution Latency:
    • Step 1 (Client →\to LDNS query + final answer): RTT0=4 ms\text{RTT}_0 = 4\text{ ms}
    • Step 2 (LDNS →\to Root referral): RTTroot=25 ms\text{RTT}_{\text{root}} = 25\text{ ms}
    • Step 3 (LDNS →\to TLD referral): RTTTLD=20 ms\text{RTT}_{\text{TLD}} = 20\text{ ms}
    • Step 4 (LDNS →\to Authoritative answer): RTTauth=35 ms\text{RTT}_{\text{auth}} = 35\text{ ms}
    • Total Cold Resolution Delay: Tcold=RTT0+RTTroot+RTTTLD+RTTauth=4+25+20+35=84 msT_{\text{cold}} = \text{RTT}_0 + \text{RTT}_{\text{root}} + \text{RTT}_{\text{TLD}} + \text{RTT}_{\text{auth}} = 4 + 25 + 20 + 35 = \mathbf{84\text{ ms}}
  2. Warm TLD Cache Latency:
    • If the TLD server is cached, the LDNS skips querying the Root server: Twarm_TLD=RTT0+RTTTLD+RTTauth=4+20+35=59 msT_{\text{warm\_TLD}} = \text{RTT}_0 + \text{RTT}_{\text{TLD}} + \text{RTT}_{\text{auth}} = 4 + 20 + 35 = \mathbf{59\text{ ms}}
  3. Full Hit Cache Latency:
    • If the www.example.com record is cached locally: Thit=RTT0=4 msT_{\text{hit}} = \text{RTT}_0 = \mathbf{4\text{ ms}}
    • Conclusion: Local DNS caching reduces resolution time by over 95%95\% (84 ms→4 ms84\text{ ms} \to 4\text{ ms}).

Example 2: The 512-Byte UDP Limit, Truncation (TC) & EDNS0 Buffer Sizing​

Problem Statement: A DNS response packet contains 12 A records and 4 cryptographic RRSIG (DNSSEC) signatures.

  • Standard DNS header: 12 bytes12\text{ bytes}.
  • Question section: 28 bytes28\text{ bytes}.
  • Each A resource record: 16 bytes16\text{ bytes}.
  • Each RRSIG resource record: 185 bytes185\text{ bytes}.
  1. Calculate the total size of the DNS response payload.
  2. What happens if a legacy DNS client queries a server over standard UDP without EDNS0?
  3. How does Extension Mechanisms for DNS (EDNS0 - RFC 6891) resolve this without falling back to TCP?

Step-by-Step Solution:

  1. Calculate DNS Response Size: Header=12 bytes\text{Header} = 12\text{ bytes} Question=28 bytes\text{Question} = 28\text{ bytes} Answers (A records)=12×16 bytes=192 bytes\text{Answers (A records)} = 12 \times 16\text{ bytes} = 192\text{ bytes} Signatures (RRSIG records)=4×185 bytes=740 bytes\text{Signatures (RRSIG records)} = 4 \times 185\text{ bytes} = 740\text{ bytes} Total Size=12+28+192+740=972 bytes\text{Total Size} = 12 + 28 + 192 + 740 = \mathbf{972\text{ bytes}}
  2. Behavior on Legacy UDP:
    • RFC 1035 limits standard UDP DNS payloads to 512 bytes512\text{ bytes}.
    • Because 972 bytes>512 bytes972\text{ bytes} > 512\text{ bytes}, the server truncates the response, sets the TC (Truncation) bit to 1 in the DNS header, and sends only the partial 512 bytes.
    • The client sees TC=1\text{TC} = 1, discards the UDP response, establishes a full TCP connection (3-way handshake +1 RTT+ 1\text{ RTT} penalty), and re-issues the query over TCP port 53.
  3. EDNS0 Resolution:
    • Under EDNS0, the client includes an OPT pseudo-RR in the request declaring an extended UDP payload buffer of 4,096 bytes4,096\text{ bytes}.
    • The server sends the full 972 bytes972\text{ bytes} in a single UDP packet without setting the TC flag, eliminating the TCP handshake penalty completely!

Example 3: TTL Caching Window & Traffic Shedding Analysis​

Problem Statement: A high-traffic news website receives 10,00010,000 page views per second from visitors across various networks. There are 500500 unique recursive ISP resolvers querying the website's authoritative nameserver.

  1. If the website's A record has a Time-To-Live of TTL=60 seconds\text{TTL} = 60\text{ seconds} (typical for fast failover), calculate the maximum number of queries the authoritative nameserver receives per hour.
  2. If the website increases its TTL\text{TTL} to 3600 seconds3600\text{ seconds} (1 hour1\text{ hour}), calculate the new query volume per hour and the percentage reduction in authoritative DNS server load.

Step-by-Step Solution:

  1. Query Volume at TTL=60 seconds\text{TTL} = 60\text{ seconds}:
    • Once a resolver caches the record, all users on that resolver are served from cache for 60 seconds.
    • Each of the 500 resolvers queries the authoritative server once every 60 seconds: Queries per minute=500 queries\text{Queries per minute} = 500\text{ queries} Queries per hour=500×60=30,000 queries/hour\text{Queries per hour} = 500 \times 60 = \mathbf{30,000\text{ queries/hour}}
  2. Query Volume at TTL=3600 seconds\text{TTL} = 3600\text{ seconds}:
    • Each resolver queries the authoritative server only once per hour: Queries per hour=500×1=500 queries/hour\text{Queries per hour} = 500 \times 1 = \mathbf{500\text{ queries/hour}}
  3. Percentage Load Reduction: Load Reduction=30,000−50030,000×100%=29,50030,000×100%=98.33%\text{Load Reduction} = \frac{30,000 - 500}{30,000} \times 100\% = \frac{29,500}{30,000} \times 100\% = \mathbf{98.33\%} Trade-off: Increasing TTL from 1 minute to 1 hour reduces DNS traffic by 98.3%98.3\%, but increases downtime recovery latency if the origin server IP changes.

🎯 Exam & Interview Pitfall Check​

Question 1: Contrast Recursive and Iterative DNS queries. Why do root DNS servers strictly reject recursive queries from recursive resolvers?

Answer:

  • Recursive Query: The querying host demands that the queried server perform the entire resolution process and return the final answer (IP address or NXDOMAIN). The intermediate server holds the query state until the process completes.
  • Iterative Query: The queried server responds with the best answer it currently possesses: either the requested record (if cached/authoritative) or a referral containing the IP address of the next nameserver down the tree. The querying host is responsible for issuing the subsequent query.
  • Why Root Servers Reject Recursive Queries: Root servers handle hundreds of billions of requests daily. If root servers accepted recursive queries, they would have to open TCP/UDP sockets to thousands of TLD servers, maintain connection state tables for millions of concurrent pending requests, and buffer intermediate responses. This would exhaust root server memory and compute, making them trivial targets for Denial of Service (DoS) attacks. Iterative processing allows root servers to respond statelessly in microseconds.

Question 2: Explain the role of the CNAME, NS, and MX resource records. Why can a CNAME record not coexist with an MX or SOA record for the apex domain (example.com)?

Answer:

  • CNAME (Canonical Name): Maps an alias hostname to its true canonical hostname (e.g. ftp.example.com -> server1.example.com).
  • NS (Name Server): Specifies the authoritative nameserver responsible for managing a particular zone.
  • MX (Mail Exchanger): Specifies the mail server designated to receive incoming SMTP emails for the domain, with an assigned preference weight.
  • Why CNAME Cannot Coexist at Apex: Per RFC 1912 (Section 2.4), if a CNAME record exists for a name, no other resource record of any type may exist for that same name. The apex domain (example.com) MUST contain an SOA record (defining zone authority) and an NS record (delegating nameservers). If a CNAME were placed at the apex, it would supersede and invalidate the SOA and NS records, breaking DNS resolution for the entire zone.
Core Conceptual Questions
  • What are DNS Glue Records?: When a domain's authoritative nameserver has a hostname within that same domain (e.g. authoritative server for binarydose.com is ns1.binarydose.com), resolving binarydose.com creates a circular dependency: to find ns1.binarydose.com, you must query ns1.binarydose.com! The parent TLD server resolves this by providing Glue Records: an A record containing the raw IP address of ns1.binarydose.com packaged alongside the NS delegation.
  • Why does DNS use UDP by default instead of TCP?: UDP requires zero connection-setup overhead (no 3-way handshake) and maintains zero server connection state. A complete DNS query and answer can complete in a single Round Trip Time (1×RTT1 \times RTT).
Common Interview Traps
  • Trap: Assuming DNSSEC Encrypts DNS Queries: DNSSEC does NOT provide confidentiality. DNS queries and responses remain readable plaintext over the wire. DNSSEC provides only integrity and authenticity (proving the record was not altered). Confidentiality requires DNS over HTTPS (DoH) or DNS over TLS (DoT).
  • Trap: Believing there are only 13 Physical Root DNS Servers: There are only 13 logical IP addresses (a.root-servers.net through m.root-servers.net) due to historical 512-byte UDP packet size limits. However, each logical identity is deployed across hundreds of physical servers worldwide using BGP Anycast routing, totaling over 1,500 physical server instances.
🗺️View Complete Computer Networks Roadmap & Syllabus
← Previous Topic8.1 Client-Server Architecture vs Peer-to-Peer (P2P)Next Topic →8.3 Hypertext Transfer Protocol: HTTP/1.0, HTTP/1.1, HTTP/2 & QUIC
💬

Discussion & Doubts