DNS
The Domain Name System: a distributed, hierarchical database that maps host names to IP addresses; the name hierarchy (root, top-level, second-level domains) and zones, name servers (root, TLD, authoritative, local), resource records (A, NS, CNAME, MX and others), the message format byte by byte (header, question, answer with name compression), recursive and iterative resolution, caching with time-to-live and its effect on the number of messages and the delay, and DNS over UDP port 53; the messages were encoded by code and decoded by the real dig program, and the resolution counts were recomputed independently.
Why it exists
People use names such as www.example.com; IP routers need addresses such as 93.184.216.34. The Domain Name System (DNS) translates between them. It cannot be one file on one machine: billions of names, changes every minute and the need for the service never to stop. DNS is therefore a distributed database run by a hierarchy of name servers, queried by a simple protocol over UDP. It is an application layer protocol whose messages are carried by UDP (UDP and ports).
Prerequisites
You need UDP and port numbers (UDP and ports).
Precise definitions
Names. A domain name is a sequence of labels separated by dots, read from the most specific (left) to the root: www.example.com. A label has at most bytes, a whole name at most bytes (quoted). The names form a tree: the root (written as an empty label), then top-level domains (com, org, edu, in, ...), then second-level domains (example.com) and so on.
Zones and name servers. The tree is cut into zones; each zone is managed by an organisation which runs authoritative name servers that hold the records of the zone and the delegation (NS records) of its subzones. Kinds of servers:
- root servers: know the servers of every top-level domain;
- TLD servers (
.com,.org, country codes): know the authoritative servers of each registered domain below them; - authoritative servers of an organisation: have the records for its own hosts;
- the local (recursive) DNS server of an ISP, university or company: the server to which hosts send their queries; it does the searching and caches the results. It is not part of the hierarchy.
Resource records. A record is (class is almost always IN, the Internet). Types:
| type | data |
|---|---|
| A | the IPv4 address of a host name (AAAA: IPv6 address) |
| NS | the name of an authoritative name server of a domain (used for delegation) |
| CNAME | the canonical name for an alias (ftp.example.com is an alias of www.example.com) |
| MX | the mail server of a domain, with a preference number (lowest first) |
| PTR | the name of an address (reverse lookup); SOA, TXT: administrative data (quoted) |
The TTL (time to live) is the number of seconds for which a cache may keep the record.
Messages. Query and response have the same format: a -byte header (identification, flags, counts of questions, answers, authority records and additional records), then the question section, the answer section, the authority section and the additional section. A query goes in a UDP datagram to port of the server; the response comes back to the sender's port (TCP port is used for large answers and zone transfers, quoted).
How it works
The message, byte for byte
A DNS query and its answer, byte by byte (www.example.com, type A): start
Computed by a script, not typed| field | bytes (hexadecimal) | meaning |
|---|---|---|
| query: identification | ||
| query: flags | ||
| query: questions | ||
| query: answers | ||
| query: authority | ||
| query: additional | ||
| query: label 3 'www' | ||
| query: label 7 'example' | ||
| query: label 3 'com' | ||
| query: root label | ||
| query: type | ||
| query: class | ||
| response: answer name | ||
| response: type | ||
| response: class | ||
| response: TTL | ||
| response: data length | ||
| response: address |
Step 0
The query is 33 bytes, the response 49 bytes (the response repeats the header and question of the query, flags 0x8580: QR = 1, AA = 1, RD = 1, RA = 1, and adds one answer of 16 bytes). Both were built by the encoder of this site and decoded by the real dig program (see the verification notes). The messages travel in UDP datagrams to port 53.
The query for the address of www.example.com takes bytes: the header (), the name as length-prefixed labels (3www7example3com0, bytes) and type and class (). The identification is chosen by the client and is repeated in the reply so that the client can match it. The flags say: it is a query (), recursion is desired (). The response repeats the question and appends the answer; its name field is the two-byte pointer C0 0C (name compression): the two top bits mean "pointer" and the remaining bits give the offset () of the name already present in the message. The flags : it is a response, the server is authoritative (), recursion was desired and is available (). A real dig program decoded these exact messages (see the notes).
Resolution
A host asks its local DNS server (a recursive query: "get me the answer"). The local server, if it does not have the answer in its cache, asks the hierarchy with iterative queries: each server either gives the answer or a referral ("I do not know, ask this server"):
Resolving www.example.com with a cold cache: start
Computed by a script, not typed| message | from → to | content |
|---|---|---|
| message 1 | ||
| message 2 | ||
| message 3 | ||
| message 4 | ||
| message 5 | ||
| message 6 | ||
| message 7 | ||
| message 8 |
Step 0
Host → local DNS server (recursive), then the local server contacts the root, the .com server and the authoritative server of example.com in turn (iterative). Eight messages in all.
The sequence for a cold cache: host local server; local root (referral to the .com servers); local .com server (referral to the authoritative server of example.com); local authoritative server (the answer); local host. Eight messages in all: two for the host's exchange with the local server and two for each of the three servers contacted; in general messages if the local server contacts servers of the hierarchy. In the fully recursive variant each server queries the next one itself on behalf of the previous one, and the number of messages is the same; the difference is who does the work and where the answer is cached.
Caching
The local server stores answers (for their TTL) and also the referrals (the names of the .com and example.com servers, with a long TTL). This avoids most of the hierarchy:
Caching in the local DNS server: start
Computed by a script, not typed| query | messages | time | servers contacted |
|---|---|---|---|
| www.example.com (t = 0 s) | |||
| www.example.com (t = 0 s) | |||
| mail.example.com (t = 0 s) | |||
| www.other.com (t = 0 s) | |||
| www.example.com (t = 301 s) |
Step 0
Answers have TTL 300 s, delegations 3600 s. Round-trip times: host–local server 10 ms, root 40 ms, .com server 30 ms, authoritative servers 50 ms (assumed values). Time counts only round trips (no processing).
The first query for www.example.com costs messages and ms (with the assumed round-trip times). The same name again is answered from the cache: messages, ms. A different host in the same domain (mail.example.com) needs only the authoritative server ( messages); a different domain under .com skips the root ( messages); after s the answer has expired but the referral to the authoritative server has not, so messages. Caching is why the root servers are not overwhelmed. The price is that a changed record is seen by others only after the old TTL runs out.
Worked examples
EX 1Message count
EasyA host asks the local server for a name that is not in its cache; the local server asks the root, the TLD server and the authoritative server. Messages: (host to local) (three query-response pairs) (answer to the host) . If the local server already knows the authoritative server: . If it has the answer: .
EX 2Resolution time
MediumRound-trip times: host to local ms, local to root ms, to the TLD server ms, to the authoritative server ms. Cold query: ms. With the delegation cached: ms. From the cache: ms. A web page that needs the TCP handshake ( RTT) and the request ( RTT) with a server at RTT ms after a ms lookup takes ms until the first byte of the page arrives.
EX 3Reading a query
MediumThe first bytes 12 34 01 00 00 01 00 00 00 00 00 00 are the header: id , flags (query, recursion desired), question, no other records. The name 03 77 77 77 07 ... is www.example.... Type 00 01 is A, class 00 01 is IN.
EX 4Typical questions
GATE level(a) "Which transport protocol and port does DNS use for ordinary queries?" UDP, port . (b) "Which record gives the mail server?" MX. (c) "Which record maps an alias to the real name?" CNAME. (d) "What does a root server return for www.example.com?" A referral to the .com servers (NS records), not the address. (e) "Which DNS server holds the actual A record of www.example.com?" The authoritative server of example.com. (f) "What is the purpose of the TTL?" It limits how long a cache may use a record. (g) "Recursive or iterative: which does a host use?" Recursive towards its local server; the local server uses iterative queries.
Cheat box
Cheat box
- Name = labels (at most bytes each), name at most bytes; hierarchy root, TLD, domain.
- Servers: root, TLD, authoritative, local (recursive resolver with a cache).
- Records: A, AAAA, NS, CNAME, MX, PTR; each with a TTL.
- Message: -byte header, question, answer, authority, additional; UDP port ; pointer
C0xxcompresses names. - Cold resolution: host to local (recursive), local to root, TLD, authoritative (iterative): messages; cache cuts it to , or .
Traps and GATE patterns
Connections
Across subjects
No cross-subject links yet.
Within this subject
DNS rides on UDP datagrams (UDP and ports), which an application sends with sendto (socket API); a browser resolves the name of a site before it opens the TCP connection of an HTTP request (HTTP). The hierarchy of servers with delegation resembles a tree search (trees).
PYQs
6 previous year questions from your book. I re-solved each one myself (2 by running or simulating, 4 by reasoning only); the book's key is shown next to my answer. All PYQs
Which one of the following protocols is NOT used to resolve one form of address to another one?
- (a)DNS
- (b)ARP
- (c)DHCP
- (d)RARP
A user starts browsing a webpage hosted at a remote server. The browser opens a single connection to fetch the entire webpage from the server. The webpage consists of a top-level index page with multiple embedded image objects. Assume that all caches (e.g., DNS cache, browser cache) are all initially empty. The following packets leave the user's computer in some order. (i) HTTP GET request for the index page. (ii) DNS request to resolve the web server's name to its IP address. (iii) HTTP GET request for an image object. (iv) TCP SYN to open a connection to the web server. Which one of the following is the CORRECT chronological order (earliest in time to latest) of the packets leaving the computer?
- (a)(iv), (ii), (iii), (i)
- (b)(iv), (ii), (i), (iii)
- (c)(ii), (iv), (i), (iii)
- (d)(ii), (iv), (iii), (i)
Suppose in a web browser, you click on the www . gate-2023 . in URL. The browser cache is empty. The IP address for this URL is not cached in your local host, so a DNS lookup is triggered (by the local DNS server deployed on your local host) over the 3- tier DNS hierarchy in an iterative mode. No resource records are cached anywhere across all DNS servers. Let RTT denote the round trip time between your local host and DNS servers in the DNS hierarchy. The round trip time between the local host and the web server hosting www.gate-2023.in is also equal to RTT. The HTML file associated with the URL is small enough to have negligible transmission time and negligible rendering time by your web browser, which references 10 equally small objects on the same web server. Which of the following statements is/are CORRECT about the minimum elapsed time between clicking on the URL and your browser fully rendering it?
- (a)7 RTTs, in case of non-persistent HTTP with 5 parallel TCP connections.
- (b)5 RTTs, in case of persistent HTTP with pipelining.
- (c)9 RTTs, in case of non-persistent HTTP with 5 parallel TCP connections.
- (d)6 RTTs, in case of persistent HTTP with pipelining. COMPUTER NETWORK
Consider the resolution of the domain name www.gate.org.in by a DNS resolver. Assume that no resource records are cached anywhere across the DNS servers and that iterative query mechanism is used in the resolution. The number of DNS query- response pairs involved in completely resolving the domain name is ___________.
Identify the correct sequence in which the following packets are transmitted on the network by a host when a browser requests a webpage from a remote server, assuming that the host has just been restarted.
- (a)HTTP GET request, DNS query, TCP SYN
- (b)DNS query, HTTP GET request, TCP SYN
- (c)DNS query, TCP SYN, HTTP GET request
- (d)TCP SYN, DNS query, HTTP GET request
Which one of the following uses UDP as the transport protocol?
- (a)HTTP
- (b)Telnet
- (c)DNS
- (d)SMTP COMPUTER NETWORK
Self-check
Question 1
How many DNS messages does a cold lookup produce when the local server contacts a root, a TLD and an authoritative server?
Show answerHide
( with the host and with the three servers).
Question 2
Which resource record is used by a server to delegate a subdomain?
Show answerHide
NS records (naming the authoritative servers of the subdomain).
Question 3
Why can two lookups of the same name give different delays?
Show answerHide
The second may be answered from the local server's cache, which skips the root, TLD and authoritative servers.
Revision card
One-screen revision
- DNS: distributed hierarchical database; UDP port ; local resolver with cache.
- Records A, NS, CNAME, MX with TTL; referral from root and TLD, answer from the authoritative server.
- Cold lookup messages, cache , delegation cached .
References
- ·Kurose, Ross, Computer Networking: A Top-Down Approach (8th edition), Chapter 2, Section 2.4 (DNS)
- ·Tanenbaum, Wetherall, Computer Networks (5th edition), Chapter 7, Section 7.1 (DNS: the Domain Name System)
- ·Forouzan, Data Communications and Networking (5th edition), Chapter 26 (Domain Name System)
Verification
scripts/enum-checks/cn_app_check.py: (1) the DNS encoder / decoder of scripts/cn_app.py round-trips 2000 random queries and responses (names of 1 to 4 labels, types A, MX, NS, CNAME, TXT) and rejects labels over 63 bytes and names over 255 bytes; the bytes of the query for example.com equal the hand-derived hexadecimal string; (2) A UDP server built on the encoder was queried by the REAL dig program: dig decoded and printed the A, MX (two records), CNAME and NS answers exactly, reported status NXDOMAIN and the header flags 'qr aa rd ra' for an unknown name, and the server decoded the queries that dig really sent (class IN, recursion desired, EDNS record in the additional section ignored); (3) the resolver of scripts/cn_app.py (local server with a cache of answers (TTL 300 s) and delegations (TTL 3600 s), root / .com / authoritative servers) needs 8 messages for a cold query, 2 for the same name again, 4 for another host in the same domain, 6 for another domain under .com, and 4 when the answer expired but the delegation did not; these counts equal an independent count on 300 random sequences of 30 queries with random time steps. The time column of the cache table adds the assumed round-trip times. MODEL: one root, one .com server and two authoritative servers; no packet loss, no negative caching, no CNAME chains, no additional (glue) records, answers are not truncated. QUOTED from the RFCs and textbooks, not verified here: the number and role of root servers (13 logical addresses), the record types beyond those tested (AAAA, PTR, SOA, TXT semantics), the 512-byte limit of UDP messages without EDNS and the use of TCP port 53 for zone transfers and large answers, the maximum name and label lengths (verified by the encoder's own assertions only), DNS caching of negative answers, and the role of recursive resolvers of ISPs. Textbook chapter references are from memory. SECOND PASS (2026-11-02, done by the assistant, not a human check): every Self-check question was solved before the printed answer was read and all agreed; the definitions, worked examples, cheat box and traps were read claim by claim and the numbers re-derived by hand or by a small script (CRC remainders, binomial tail, checksums); long C programs were not re-read line by line (they are compiled and compared by npm run verify:c, and their printed outputs were checked against the prose). No defect found. Status raised to self-checked; verified needs a textbook or human check.
last verified: never
My notes (saved in this browser)