Every time you type a domain name into a browser, an invisible chain of queries fires across the internet. The response comes back in milliseconds. This is the DNS — the Domain Name System — and understanding it is fundamental to every sysadmin and network engineer.

What is DNS?

The Domain Name System translates human-readable names like rootlog.in into machine-readable IP addresses like 185.199.108.153. Without DNS, you would browse the internet by memorising IP addresses — which does not scale.

DNS is a distributed, hierarchical database. No single server holds the entire mapping. Instead, the namespace is split across millions of servers, each responsible for a small slice. This design is codified in RFC 1034 (Domain Names — Concepts and Facilities) and RFC 1035 (Domain Names — Implementation and Specification) — the foundational specifications that every DNS implementation follows. If you read any two RFCs on DNS, make it these.

Reference: P. Mockapetris, “RFC 1034 — Domain Names - Concepts and Facilities,” 1987. https://datatracker.ietf.org/doc/rfc1034/ Reference: P. Mockapetris, “RFC 1035 — Domain Names - Implementation and Specification,” 1987. https://datatracker.ietf.org/doc/rfc1035/

The Domain Hierarchy

A fully qualified domain name (FQDN) like blog.rootlog.in is read right-to-left:

blog.rootlog.in.
    |     |    |
    |     |    +-- root zone (.)
    |     +------ TLD (.in)
    +------------ second-level domain (rootlog.in)

• Root zone (.): The top of the tree. Managed by ICANN and operated by 12 independent organisations.
• Top-level domain (.in, .com, .org): Managed by registries like INRegistry, Verisign, or PIR.
• Second-level domain (rootlog.in): Registered by you from a registrar.
• Subdomain (blog): Created by you in your own DNS zone.

Root Servers

Root servers are the ultimate starting point for every DNS resolution. They do not know where blog.rootlog.in is — but they know where to find the .in nameservers.

The root zone is served from 13 logical identities, labelled A through M — a number chosen because a DNS response containing all root NS records and their glue A/AAAA records must fit within a single 512-byte UDP packet (RFC 1035 section 4.2.1). With the EDNS0 extension (RFC 6891), responses can reach 4096 bytes, but the 13-identity limit is historical convention.

There are 13 logical identities, but each one runs on hundreds of physical servers worldwide using anycast routing (RFC 4786). A single query to a.root-servers.net reaches the nearest physical instance — typically within 5-20 ms from anywhere on the planet. This anycast distribution makes the root zone resilient against DDoS attacks and regional outages.

Pro tip: You can see which root server instance you hit by checking the Advisory section of a dig +trace output. Different instances of the same letter may respond depending on your geographic location.

Real-world context: During the 2016 Mirai botnet DDoS attack against Dyn, root server anycast absorbed much of the collateral traffic. No root server became unreachable. The system was designed for this — root servers see over 100 billion queries per day across all instances combined.

Reference: Root server operations — https://root-servers.org Reference: RFC 4786 — Operation of Anycast Services. https://datatracker.ietf.org/doc/rfc4786/ Further reading: “DNS and BIND” by Cricket Liu & Paul Albitz (5th Edition, O’Reilly) — Chapters 1–3 cover the DNS hierarchy and root server architecture in depth. The book has been the canonical reference for DNS operations since 1992.

Root servers serve the root zone file — a ~2 KB file listing every TLD and its nameservers. The content of every root zone is identical on every root server instance.

How a DNS Lookup Happens

When you type rootlog.in into a browser, here is the exact sequence as defined by the DNS resolution algorithm in RFC 1034 section 4.3:

1. Check cache — The browser, operating system, and local resolver each check their DNS cache. If a valid (non-expired) record exists, resolution stops here. Check your local cache with dig +ttlid or resolvectl statistics on systemd systems.

2. Query the stub resolver — The application calls gethostbyname() or getaddrinfo() (see man 3 gethostbyname, man 3 getaddrinfo), which consults /etc/nsswitch.conf (see man 5 nsswitch.conf) for resolution order, then sends the query to the stub resolver at the address listed in /etc/resolv.conf (see man 5 resolv.conf).

3. Query the recursive resolver — The stub resolver sends a recursive query (RD=1, Recursion Desired flag set) to a configured recursive resolver — your ISP’s resolver, Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9, or a local Unbound instance.

4. Root server query — The recursive resolver asks a root server: “Where is rootlog.in?” The root server replies with a referral to the .in TLD nameservers. This is not an answer — it is a pointer to the next level of the hierarchy.

5. TLD server query — The recursive resolver asks a .in nameserver: “Where is rootlog.in?” The TLD server replies: “Ask dns1.p01.nsone.net and dns2.p01.nsone.net.”

6. Authoritative server query — The recursive resolver asks dns1.p01.nsone.net: “What is the A record for rootlog.in?” The authoritative server replies: “rootlog.in has A record 185.199.108.153.”

7. Return and cache — The recursive resolver returns 185.199.108.153 to the stub resolver with the AA (Authoritative Answer) flag set, confirming the data came directly from the zone owner. The stub resolver passes the result to the application. The resolver caches the result for the duration of the TTL.

Pro tip: The +trace flag on dig is the single most effective DNS debugging tool. It performs iterative queries (RD=0) at each level of the hierarchy and prints every step with timing:

dig +trace rootlog.in

Each line shows the query time in milliseconds. If a step takes >100ms, that server may be slow or overloaded. If a step fails, you know exactly where the chain breaks — invaluable for troubleshooting delegation issues.

Application          Stub Resolver       Recursive Resolver    Root    .in TLD   rootlog.in NS
    |                     |                     |               |        |           |
    |-- gethostbyname --> |                     |               |        |           |
    |                     |-- recursive ------->|               |        |           |
    |                     |                     |-- root ------->|        |           |
    |                     |                     |<-- .in NS -----|        |           |
    |                     |                     |-- .in TLD ---->|--------|           |
    |                     |                     |<-- rootlog.in NS -------|-----------|
    |                     |                     |-- A query ------------>|---------->|
    |                     |                     |<-- 185.199.108.153 ----|<----------|
    |                     |<-- result ---------|               |        |           |
    |<-- 185.199.108.153 -|                     |               |        |           |

The 13 Root Servers — Why 13?

DNS messages over UDP are limited to 512 bytes (with EDNS0 extension, up to 4096 bytes). A root server response must fit a single UDP packet without fragmentation. 13 nameserver entries with their A and AAAA glue records fit within this constraint.

Each of the 13 identities is a cluster of physical servers. For example, the F-root operated by ISC runs on hundreds of nodes across the globe. Anycast makes every query go to the nearest node automatically.

Checking the Root Zone

You can query a root server directly:

dig @a.root-servers.net . ns

This returns the root zone — the list of all TLD nameservers. Compare with the official root zone file at https://www.internic.net/domain/root.zone.

To trace a full resolution path:

dig +trace rootlog.in

The +trace flag walks the entire chain: root → TLD → authoritative, printing each step with timing. Internally, dig +trace sets RD=0 (no recursion) and follows referrals manually — the same algorithm a recursive resolver uses.

Pro tip: Add +additional to see glue records in the trace output. Glue records are the A/AAAA records for the NS names that sit inside the zone itself — without them, resolvers would have a chicken-and-egg problem resolving ns1.rootlog.in when rootlog.in itself is the zone being queried.

Hands-on exercise: Run dig +trace rootlog.in +additional and identify the glue records at each delegation point. You should see NS records followed immediately by their A records in the ADDITIONAL section.

Key Takeaways

• DNS is a hierarchical, distributed database rooted in the root zone (RFC 1034/1035).
• 13 root server identities (A–M) serve the root zone, each a global anycast cluster operated by independent organisations — see the full list and real-time status at https://root-servers.org.
• Every DNS lookup walks a chain: root → TLD → authoritative → answer. Use dig +trace to see the path.
• Root servers provide referrals, not answers — they point you to the next level.
• Anycast routing (RFC 4786) makes the 13 identities globally distributed and DDoS-resilient.
• The 512-byte UDP limit (RFC 1035) historically capped the root zone at 13 NS entries; EDNS0 (RFC 6891) raised the ceiling but the convention persists.
• For the definitive deep dive: “DNS and BIND” by Cricket Liu (O’Reilly, 5th Ed.) — the canonical text since 1992.

In the next article, we will look at resolvers — what makes a query recursive versus iterative, and how stub resolvers differ from full resolvers.