Introduction

People use names such as www.example.com; IP needs addresses. The Domain Name System maps between them, and also tells mail systems where to deliver mail and gives aliases. It is a distributed, hierarchical database: no server holds all names. The namespace is a tree. Each zone, the part administered together excluding delegated child zones, is served by its authoritative name servers; resolvers walk the tree from the root downwards, caching what they learn so that most lookups never reach the root.

DNS is an application-layer protocol, normally carried over UDP port 53 in a single request and reply, which is why it adds little delay compared with a TCP connection. The calculations are the difference between recursive and iterative resolution, the number of messages and the delay of a lookup with and without cached data, record types, and the message format.

Prerequisites

Core concepts

The namespace

A domain name is a sequence of labels read from the most specific to the root: www.cs.example.edu. has labels www, cs, example, edu and the empty root label. Below the root are the top-level domains (generic such as com, org, edu, and country codes such as in), and below them the domains registered by organisations, which may create subdomains freely.

Limit (RFC 1035)Value
Labelat most 63 bytes
Whole name (in wire form)at most 255 bytes
Message over UDPat most 512 bytes (without extensions); larger answers are truncated (TC bit) and retried over TCP

Servers

KindRole
Root serversKnow the servers of every TLD
TLD serversKnow the authoritative servers of each domain under the TLD
Authoritative serversHold the actual records of a zone; their answers carry the AA bit
Local (recursive) resolverRun by an ISP or organisation; does lookups for hosts and caches results

The root zone is served under 13 root server identities, lettered A to M, run by 12 independent operators (one operator runs two letters). Each identity is answered by many servers at many sites, so 13 counts names, not machines (root-servers.org, consulted 2026-11-11).

Resource records

Each record is (name, TTL, class, type, value). Common types:

TypeValue
AIPv4 address
AAAAIPv6 address
NSName of an authoritative server for the domain
CNAMECanonical name for an alias
MXMail server for the domain, with a preference number
PTRName for an address (reverse lookup under in-addr.arpa)
SOAStart of authority: zone parameters

The TTL says how many seconds a resolver may cache the record.

Recursive and iterative resolution

  • Iterative query: the server answers with what it knows, either the answer or a referral ("ask these servers"). The asker then queries the next server itself.
  • Recursive query: the server takes over and returns the final answer, querying other servers as needed.

A host's stub resolver usually sends a recursive query to its local resolver, which then resolves iteratively: root, then TLD, then authoritative.

Two panels. Left, iterative: a host sends a query to its local resolver (1); the local resolver queries the root server (2) and gets a referral to the .com servers (3), queries the .com TLD server (4) and gets a referral (5), queries the authoritative server for example.com (6) and gets the address (7), and returns it to the host (8). Right, recursive: the host asks the local resolver (1), which asks the root (2), which asks the TLD server (3), which asks the authoritative server (4); answers return along the same chain (5 to 8). Each panel counts eight messages.
Figure 1. Resolving www.example.com with empty caches: iterative referrals from the local resolver (left) and a fully recursive chain (right), eight messages each.

Message format

Queries and replies share one format: a 12-byte header, then question, answer, authority and additional sections.

Header fieldBitsMeaning
ID16Matches a reply to its query
QR, Opcode, AA, TC, RD, RA, Z, RCODE1, 4, 1, 1, 1, 1, 3, 4Query or reply; kind; authoritative answer; truncated; recursion desired; recursion available; reserved; error code
QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT16 eachNumber of entries in each section

Names are encoded as length-prefixed labels ending in a zero byte: www.example.com becomes 3 www 7 example 3 com 0, 17 bytes. A repeated name can be replaced by a 2-byte pointer whose top two bits are 11 and whose other 14 bits give the offset of an earlier copy (message compression).

Mathematical explanation: messages and delay

With empty caches and a three-level lookup (root, TLD, authoritative):

ResolutionQueriesMessagesDelay
Host recursive to local, local iterative48r0+r1+r2+r3r_0 + r_1 + r_2 + r_3
Fully recursive chain48r0+r1+r12+r23r_0 + r_1 + r_{12} + r_{23}
TLD servers cached at local resolver36r0+r2+r3r_0 + r_2 + r_3
Authoritative servers of the zone cached24r0+r3r_0 + r_3
Answer cached at local resolver12r0r_0

Here r0r_0 is the host-to-local-resolver RTT and r1,r2,r3r_1, r_2, r_3 the local resolver's RTTs to the root, TLD and authoritative servers; in the recursive chain r12r_{12} is the root-to-TLD RTT and r23r_{23} the TLD-to-authoritative RTT. In general, a lookup that reaches kk servers beyond the local resolver costs 2(k+1)2(k + 1) messages. Caching is what makes DNS scale: each referral (NS records) and answer is reused until its TTL expires.

Worked examples

Example 1: delay with and without the cache

A host's RTT to its local resolver is 2 ms; the resolver's RTT to each of the root, .com and example.com servers is 30 ms.

  • Empty cache: 2+3×30=922 + 3 \times 30 = 92 ms, 8 messages.
  • .com servers cached: 2+30+30=622 + 30 + 30 = 62 ms, 6 messages (TLD, then authoritative).
  • example.com servers cached: 2+30=322 + 30 = 32 ms, 4 messages.
  • Answer cached: 2 ms, 2 messages.

Example 2: an alias

www.example.com has a CNAME record pointing to web1.example.net, which has an A record. A resolver asking for the A record of www.example.com gets the CNAME and must then resolve web1.example.net; if that name is in another zone, the lookup may need further referrals.

Example 3: mail

To send mail to [email protected], the sending server asks for the MX records of example.com, picks the one with the lowest preference number (for example 10 mx1.example.com before 20 mx2.example.com), then asks for that server's A record.

Example 4: name encoding

www.gate.example encodes as 03 77 77 77 04 67 61 74 65 07 65 78 61 6d 70 6c 65 00: 1+3+1+4+1+7+1=181 + 3 + 1 + 4 + 1 + 7 + 1 = 18 bytes. A query for it is 12 (header) + 18 (name) + 2 (type) + 2 (class) = 34 bytes of DNS message, sent in one UDP datagram.

Example 5: reverse lookup

The name for address 203.0.113.7 is looked up as a PTR record for 7.113.0.203.in-addr.arpa: the bytes are reversed so that the most specific part comes first, as in every domain name.

Important properties and observations

  • UDP for queries, TCP for zone transfers (and for answers too large for a UDP message).
  • Root and TLD servers usually answer only iteratively; recursion is the local resolver's job.
  • Caching with TTLs trades freshness for load: a changed record may be served stale until its TTL expires.
  • A name may have several A records, which lets a site spread clients over several servers.
  • DNS lookups come before connections: fetching a page from a new host starts with DNS.

Common misconceptions.

  • "The local resolver is part of the hierarchy." It is a client of it, run near the host.
  • "Recursive resolution needs fewer messages." Both need 8 here; recursion shifts the work, it does not reduce it.
  • "DNS uses only TCP" or "DNS uses only UDP." UDP port 53 is common, but TCP is valid for ordinary queries and required for general-purpose DNS implementations. AXFR uses TCP, and truncation commonly triggers TCP retry.
  • "Each label can be 255 bytes." 63 bytes per label; 255 for the whole name.

GATE examination perspective

  • Message counts. Count queries and replies; caching removes pairs.
  • Delay. Add the RTTs of each server actually contacted.
  • Recursive versus iterative. Who issues the next query.
  • Record types. A, AAAA, NS, CNAME, MX, PTR.
  • Transport and port. UDP port 53; TCP port 53 for zone transfers.

Summary

Sources

  1. A. S. Tanenbaum, D. J. Wetherall, Computer Networks, 5th ed., Pearson, 2011: Section 7.1 (DNS), Subsections 7.1.1 to 7.1.3.
  2. J. F. Kurose, K. W. Ross, Computer Networking: A Top-Down Approach, 8th ed., Pearson, 2021: Section 2.4 (DNS: The Internet's Directory Service), Subsections 2.4.1 to 2.4.3.
  3. B. A. Forouzan, Data Communications and Networking, 5th ed., McGraw-Hill, 2013: Chapter 26 (Standard Client-Server Protocols).
  4. Root Server Technical Operations Association, Root Servers, (consulted 2026-11-11): the 13 root server identities A to M and their 12 operators.
  5. P. Mockapetris, RFC 1034, Domain Names: Concepts and Facilities, 1987, Section 4.3.1 (Queries and responses: recursive and non-recursive modes), (consulted 2026-11-11).
  6. P. Mockapetris, RFC 1035, Domain Names: Implementation and Specification, 1987, Sections 2.3.4 (Size limits), 3.2.2 (TYPE values), 4.1.1 (Header section format), 4.1.4 (Message compression), 4.2.1 (UDP usage) and 4.2.2 (TCP usage), (consulted 2026-11-11).
  7. J. Dickinson et al., RFC 7766, DNS Transport over TCP: Implementation Requirements, Sections 1, 4 and 5, (consulted 2026-11-11).

Next steps