DNS Deep-Dive: The Internet Phone Book

Open a browser, type irctc.co.in, and press Enter. In well under a second, India's railway booking portal appears. But here is the strange part: your computer never actually understood the word "irctc." Computers on the internet find each other only through numbers called IP addresses — something like 203.0.113.10. Routers, the machines that physically shuttle your data across cities and oceans, have no idea what "irctc" means; they only know how to forward a packet toward a numeric address. So somewhere between you pressing Enter and the page loading, a system translated the name you typed into the number your network hardware could actually use. That translation system is the Domain Name System — DNS — arguably the most-used, least-noticed piece of infrastructure on the internet. Every WhatsApp message your phone syncs, every UPI payment confirmation your bank app fetches, every video YouTube streams begins with a DNS lookup you never see happen. This chapter takes DNS apart piece by piece: why it had to exist, why it is built as a tree instead of one giant list, exactly which messages travel back and forth when you type a web address, and who in India is actually responsible for keeping it running.

The Problem: Computers Don't Understand Names

Every device connected to the internet — your phone, the IRCTC server, the router in your school's computer lab — is identified by an IP address. The version most networks still use, IPv4, writes this as four numbers from 0 to 255 separated by dots, such as 203.0.113.10. Underneath, this is really a single 32-bit binary number; the four dotted numbers are just a human-friendlier way of writing it in four 8-bit chunks. A newer version, IPv6, uses 128 bits and is written as groups of hexadecimal digits, such as 2001:0db8:0000:0000:0000:0000:0000:00a1, because the world has now connected far more devices than IPv4's roughly 4.3 billion addresses can uniquely name. Either way, routers build their forwarding decisions purely from these numbers — a router's forwarding table has no column for "website name." If you tried to use the internet with only domain names and no translation step, every router between you and IRCTC's server would have no idea where to send your request. DNS exists to solve exactly this mismatch: humans are good at remembering words, machines are good at routing numbers, and something has to sit in between converting one into the other, on every single request, fast enough that you never notice it happening.

A Familiar Analogy: Your Phone's Contact List

You already use a system exactly like DNS every day, just at a much smaller scale. Your phone's contact list maps a human-readable name — say, "Amma" or "Class 8B Group Admin" — to the actual phone number that the mobile network's switches use to route your call. You never dial the ten-digit number; you tap the name, and your phone silently looks up the number and dials that instead. DNS does precisely this for the internet: domain names play the role of contact names, IP addresses play the role of phone numbers, and the act of "looking someone up" is called a DNS query.

Push the analogy one step further and an important difference appears. Your phone's contact list is private, stored on your device or synced only to your own account — nobody else can look up "Amma" in your phone. DNS's "contact list," by contrast, is public, shared by every device on Earth, and maintained not by one company but by millions of independent organisations working together under shared rules. That difference is the whole reason DNS needs a more elaborate design than a simple list. Formally: DNS is a distributed, hierarchical database that maps human-readable domain names to machine-usable data, most commonly IP addresses. "Distributed" means no single computer stores the entire database. "Hierarchical" means the database is organised as a tree, and answering a query means walking down that tree one level at a time rather than searching one flat list. The rest of this chapter unpacks exactly what that tree looks like and how the walk happens.

Anatomy of a Domain Name

Before looking at the tree of servers, look closely at the name itself, because the name's structure is what makes the tree navigable. Take www.irctc.co.in and read it from right to left — the opposite direction to how you'd read it aloud:

• in — the top-level domain (TLD), specifically a country-code TLD (ccTLD) assigned to India.
• co — a second-level category historically used under .in for commercial organisations, similar in spirit to how .com works globally.
• irctc — the actual name the organisation registered; this is the label that uniquely identifies IRCTC within the co.in category.
• www — a subdomain (technically called a "host" label), conventionally used to mark the main website, though an organisation could just as easily create mail.irctc.co.in or booking.irctc.co.in under the same registered name.

There is also an invisible fifth label: the root, written as a trailing dot, so the full technical name is www.irctc.co.in. — browsers simply hide that final dot because it is always the same for every domain on Earth and typing it adds nothing. Compare this to aicomputerinstitute.com: here, com is a generic TLD (originally meant for commercial entities, now open worldwide to anyone), and aicomputerinstitute is the registered second-level name — there is no extra category label in between, because generic TLDs like .com don't use the category system that older ccTLDs such as .in historically did. The general rule holds for every domain name on the internet: everything toward the right of a name is broader and shared by millions of other names; everything toward the left is progressively narrower and specific to one organisation, exactly the way an Indian postal address narrows from country to state to city to street to house number — just written in the reverse order.

DNS Is Not One Computer — It Is a Hierarchy of Delegated Authorities

Because a domain name narrows step by step, the servers that answer questions about it are organised the same way, in three broad tiers, each responsible for a narrower slice of the namespace than the one above it.

Root servers sit at the very top and answer questions about the trailing dot. There are 13 logically named root server identities — lettered a.root-servers.net through m.root-servers.net — but each letter is not one physical machine; it is hundreds of machines scattered across the world that all answer to the same address using a routing technique called anycast, so no single building or cable failure can take a root server offline. Crucially, a root server does not know IRCTC's IP address, and it does not know Google's either. All it knows is which organisations are responsible for each TLD — it can tell you "for anything ending in .in, go ask these particular servers next."

TLD servers are the second tier — for our example, the servers responsible for everything ending in .in. These servers also do not know IRCTC's IP address. They only know which organisation registered irctc.co.in and which servers that organisation designated as authoritative for it, so they hand out a further referral.

Authoritative servers are the third tier, and this is where the actual answer finally lives — the specific servers that IRCTC (or its hosting provider) configured to hold the real records for irctc.co.in, including the IP address of www.irctc.co.in.

This is called delegation, and it mirrors how India's school examination system is organised: a central board does not personally hold every student's answer script; it delegates to state boards, which delegate to individual schools, and each office knows exactly which office to forward you to next rather than trying to hold everything itself. The diagram below shows this delegation happening for our running example.

Tracing a Real Lookup, Step by Step

Note that your browser almost never talks to root, TLD, and authoritative servers directly. That legwork is handled by a recursive resolver — a server usually run by your ISP (like Jio or Airtel), or a public one you can configure yourself, such as Cloudflare's 1.1.1.1 or Google's 8.8.8.8. Your device asks the resolver one question and waits; the resolver does all the walking down the tree on your behalf. Here is the complete sequence for www.irctc.co.in, assuming nothing is cached anywhere yet:

1. Your browser checks its own tiny internal cache — no match, since this is the first visit today.
2. Your operating system checks its own resolver cache — also no match.
3. The request is forwarded to your configured recursive resolver.
4. The resolver checks its own (much larger, shared-across-many-users) cache — still no match, so it must ask the network.
5. The resolver asks a root server, "Who is responsible for .in?" The root server does not know the final IP; it replies with a referral pointing to the .in TLD servers.
6. The resolver asks a .in TLD server, "Who is authoritative for irctc.co.in?" The TLD server also does not know the final IP; it replies with a referral pointing to IRCTC's authoritative name servers (found via an NS record, explained below).
7. The resolver asks IRCTC's authoritative server directly, "What is the A record for www.irctc.co.in?" This server actually stores the answer and replies with the real IP address, plus a TTL value telling the resolver how long it may reuse this answer.
8. The resolver stores that answer in its cache for the TTL duration and finally sends the IP address back down to your operating system and browser.
9. Only now does DNS's job end. Your browser opens a completely separate connection — a TCP handshake to that IP address on port 443, followed by a TLS negotiation and then the actual HTTPS request — to fetch the webpage itself.

Every one of those numbered exchanges typically completes in a few tens of milliseconds, which is why the entire nine-step walk is invisible to you even though it happens before a single byte of the actual IRCTC homepage has been requested.

What Comes Back: DNS Record Types

DNS doesn't only store IP addresses — an authoritative server holds several kinds of records for a domain, each answering a different type of question:

• A record — maps a name to an IPv4 address. Example: www.irctc.co.in → 203.0.113.10.
• AAAA record — maps a name to an IPv6 address, needed as the world runs out of the older, shorter IPv4 addresses. Example: www.irctc.co.in → 2001:db8::a1.
• CNAME record — an alias: it points one name to another name, not directly to an IP. Example: www.aicomputerinstitute.com → aicomputerinstitute.com, so that both addresses ultimately resolve to whatever IP the second name currently has, without duplicating that IP in two places.
• MX record — tells the internet which mail server handles email for a domain, together with a priority number lower servers are tried first. Example: MX 10 mail.irctc.co.in.
• NS record — states which servers are authoritative for a domain; this is the exact record type that powers the referrals in steps 5 and 6 above.
• TTL — not a separate record type but a number, measured in seconds, attached to every single record, telling any resolver how long it is allowed to cache that answer before it must ask again.

Caching and TTL: Why the Second Visit Loads Faster

Re-querying the full nine-step chain for every single request, from every single device, would make DNS itself the internet's biggest bottleneck. Caching, governed by TTL, is what prevents that. Work through a concrete case. Suppose a school computer lab has 40 machines, and during a single ten-minute class period every machine loads aicomputerinstitute.com, whose authoritative server sets a TTL of 300 seconds (5 minutes) on its A record.

Without caching: all 40 machines would each send their own DNS query out to the internet — 40 queries leaving the lab's network.

With caching: the lab's local recursive resolver performs the full lookup once, then answers every other machine instantly from its own memory for as long as the TTL allows. Ten minutes is 600 seconds, and 600 ÷ 300 = 2, so the TTL window resets twice during the class period. In the worst case, that means only 2 fresh lookups ever leave the network — one at the start, one after the first 300 seconds expire — while the remaining 38 requests are answered locally, in well under a millisecond, without touching the internet at all. That's a reduction from 40 external queries to 2, or (40 − 2) ÷ 40 = 95% fewer queries leaving the building.

TTL is a genuine trade-off, not just a knob to set as high as possible. A long TTL (say, 86400 seconds — 24 hours) means fewer lookups and faster average response times, but if the organisation ever needs to move its server to a new IP address, resolvers around the world that cached the old answer will keep sending users to the old, possibly dead, address until their cached TTL finally expires — up to a full day of some users hitting a broken address. This is why organisations planning a server migration commonly lower their TTL to something small, like 60 seconds, a day or two in advance of the switch, perform the migration, confirm everything works, and only then raise the TTL back up — deliberately trading a short period of extra DNS traffic for the ability to fix mistakes within a minute instead of within a day.

Simulating DNS Caching in Code

The cache-then-reuse behaviour described above can be modelled directly with a Python dictionary, which is exactly the data structure real resolvers use internally (just far larger and with expiry timers attached).

dns_cache = {}

def lookup_from_authoritative(domain):
    # Stands in for the full root -> TLD -> authoritative walk.
    # 203.0.113.0/24 is a range reserved for documentation examples.
    records = {
        "irctc.co.in": "203.0.113.10",
        "aicomputerinstitute.com": "203.0.113.25",
    }
    return records.get(domain, "0.0.0.0")

def resolve(domain):
    if domain in dns_cache:
        print(f"Cache HIT for {domain} -> {dns_cache[domain]}")
        return dns_cache[domain]
    ip = lookup_from_authoritative(domain)
    dns_cache[domain] = ip
    print(f"Cache MISS for {domain}. Resolved and cached -> {ip}")
    return ip

resolve("aicomputerinstitute.com")
resolve("aicomputerinstitute.com")
resolve("irctc.co.in")

Trace it line by line. The first call looks for "aicomputerinstitute.com" in dns_cache, an empty dictionary at this point, so the condition is false; it falls through to lookup_from_authoritative, gets back "203.0.113.25", stores it in the cache, and prints a MISS line. The second call looks for the same domain — this time it is in dns_cache from the previous line, so it prints a HIT line and returns instantly without calling lookup_from_authoritative at all. The third call is for a different domain, "irctc.co.in", which has never been looked up, so it MISSes and gets cached too. The three printed lines are, in exact order:

Cache MISS for aicomputerinstitute.com. Resolved and cached -> 203.0.113.25
Cache HIT for aicomputerinstitute.com -> 203.0.113.25
Cache MISS for irctc.co.in. Resolved and cached -> 203.0.113.10

This tiny program captures the essential logic of every recursive resolver on the planet: check the cache first, only do the expensive multi-step walk on a miss, and remember the answer afterward. Real resolvers add one more ingredient this simplified version skips — each cached entry silently expires and is evicted once its TTL runs out, forcing the next lookup after that point back to a MISS even for a previously-seen domain.

Two Common Misconceptions, Corrected

Misconception 1: "Root DNS servers store the IP address of every website in the world." This feels intuitive because "root" sounds like it should be the ultimate source of truth, but it is backwards. A root server stores almost nothing about individual domains — it only stores which organisation is responsible for each TLD (around 1,500 TLDs exist today, a small, manageable list). It has never even heard of irctc.co.in specifically; it only knows enough to point a resolver toward the .in TLD servers, who in turn only know enough to point further toward IRCTC's own authoritative servers. The actual answer for any specific domain lives only at that domain's own authoritative servers — nowhere else. This delegation is precisely what lets the system scale to over 350 million registered domain names without any single machine needing to remember all of them.

Misconception 2: "DNS is how the actual webpage gets downloaded to your browser." DNS's entire responsibility ends at step 8 in the walk above, the moment it hands your browser an IP address. Fetching the actual HTML, images, and scripts of the IRCTC homepage happens afterward, over an entirely separate conversation — a TCP connection and, for HTTPS sites, a TLS negotiation — directly between your browser and that IP address, in which no DNS server participates at all. A useful mental check: if you already know a website's numeric IP address, you can often type it straight into the browser's address bar and skip DNS entirely for that one request (this doesn't work for every site, because many web hosting providers place several different websites on the very same IP address and rely on the hostname you sent, not just the IP, to know which one to actually serve you) — but the core point stands: DNS's job is strictly to hand over an address, not to hand over content.

DNS in India: Who Runs .in?

The global DNS root and the assignment of each TLD to a responsible organisation is coordinated by ICANN — the Internet Corporation for Assigned Names and Numbers, a nonprofit that oversees this system worldwide. ICANN delegates each country-code TLD to a national registry rather than running it directly. For India's .in, that registry role is held by NIXI — the National Internet Exchange of India — a not-for-profit organisation set up under India's Ministry of Electronics and Information Technology. NIXI operates the authoritative infrastructure for .in and accredits the registrars — the companies you actually buy a domain name from — who sell and manage registrations on NIXI's behalf.

Historically, .in only allowed registration under fixed second-level categories: .co.in for companies (which is exactly the pattern IRCTC's own domain follows), .net.in for network providers, .org.in for organisations, .ac.in for academic institutions, .gov.in for government bodies, and a few others. In the mid-2000s, NIXI also opened .in for direct second-level registration — meaning an organisation could register a name straight under .in (such as example.in) without going through one of the older categories — giving Indian individuals and businesses a second, shorter option alongside the original category-based structure that domains like irctc.co.in still use today.

Check Your Understanding

1. A domain's A record has a TTL of 86,400 seconds. The organisation changes the server's IP address today. Roughly how long could some resolvers around the world keep sending users to the old, now-wrong address? Why does deliberately lowering the TTL a day or two before a planned migration reduce this risk?
2. For the domain results.board.ac.in, identify, reading right to left: the TLD, the second-level category, and the label that names the specific organisation.
3. True or false, with a one-sentence justification: "The root DNS servers store the IP addresses of every website in the world."
4. A recursive resolver has never seen examboard.gov.in before. Put these four events in the correct order: (a) the resolver asks the .in TLD server; (b) the resolver asks a root server; (c) the resolver returns the final IP address to the browser; (d) the resolver asks the authoritative server for examboard.gov.in.
5. A college computer lab has 60 systems. All 60 load the same results.ac.in page within an 8-minute exam-result rush, and the site's DNS TTL is set to 240 seconds. In the worst case, how many fresh DNS queries leave the lab's network, and how many are answered instantly from the local cache? Show the arithmetic.
6. Using the resolve() function from the code section, what are the exact three lines printed by this call sequence: resolve("irctc.co.in"), resolve("aicomputerinstitute.com"), resolve("irctc.co.in")?

Summary

• DNS translates human-readable domain names into machine-usable data, most often IP addresses, because routers only forward packets using numbers, never names.
• DNS is a distributed, hierarchical database, not one server: root servers delegate to TLD servers, which delegate to authoritative servers — each level only knows where to send the query next, and only the authoritative level actually holds the final answer.
• A recursive resolver, often run by your ISP or a public service such as 1.1.1.1, performs the multi-step walk down the tree on your behalf and caches the answer for the record's TTL so that repeated requests are answered instantly.
• Different record types carry different kinds of answers: A and AAAA for IPv4/IPv6 addresses, CNAME for aliases, MX for mail servers, and NS for the referrals that make delegation work at all.
• TTL length is a genuine trade-off between fewer network queries (long TTL) and faster recovery from mistakes (short TTL); organisations deliberately shorten it before risky changes.
• DNS's responsibility ends the instant it returns an IP address — the actual webpage transfer happens afterward over a completely separate TCP/TLS/HTTP conversation.
• India's .in ccTLD is delegated by ICANN to NIXI, a not-for-profit under India's Ministry of Electronics and Information Technology, which accredits registrars and has long used category-based second-level domains like .co.in, .ac.in, and .gov.in alongside direct .in registration.

Answer Key

• 1. Up to 86,400 seconds (24 hours), since a resolver that cached the old answer is allowed to keep reusing it without asking again until the TTL expires. Lowering the TTL in advance shrinks that worst-case window to match the shorter TTL, so any mistake is corrected within minutes rather than a full day.
• 2. TLD: in. Second-level category: ac (academic institutions). Organisation label: board.
• 3. False — root servers only know which servers are responsible for each TLD; they never store individual domains' IP addresses, which live only at each domain's own authoritative servers.
• 4. Correct order: b, a, d, c (root, then TLD, then authoritative, then the answer returns to the browser).
• 5. 8 minutes = 480 seconds; 480 ÷ 240 = 2 TTL windows, so at most 2 fresh queries leave the network, and the remaining 60 − 2 = 58 requests are answered from the local cache.
• 6. Cache MISS for irctc.co.in. Resolved and cached -> 203.0.113.10, then Cache MISS for aicomputerinstitute.com. Resolved and cached -> 203.0.113.25, then Cache HIT for irctc.co.in -> 203.0.113.10.

Think About It

Think about this: How would you explain dns deep-dive: the internet phone book to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where dns deep-dive: the internet phone book is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting dns deep-dive: the internet phone book to at least 3 other topics you have studied.