LinkedIn Hook

You type google.com and hit Enter.

Your browser doesn't know where Google lives. Neither does your router. Neither does your ISP.

But within milliseconds — someone figures it out.

That's DNS. And most engineers can't explain it past "it translates domain names to IP addresses."

Here's what's actually happening:

Your computer is essentially flipping through the world's largest phone book — one that is distributed across thousands of servers, organized in a strict hierarchy, and responds in under 50ms.

Without DNS, you'd have to memorize 142.250.80.46 for Google, 13.32.99.88 for GitHub, and 151.101.1.140 for Reddit.

And with IPv6? Try memorizing 2001:4860:4860::8888. Good luck.

DNS is not optional plumbing. It's the reason the internet is usable by humans.

Lesson 6.1 is live — the full breakdown of what DNS is, how the domain hierarchy works, and who the players are.

Read the full lesson → https://github.com/your-repo/interview-prep/networking/ch06-dns/01-what-is-dns.md

#DNS #Networking #InterviewPrep #SoftwareEngineering #BackendDevelopment #SystemDesign #TechEducation

What is DNS? thumbnail

What You'll Learn

Why DNS exists and the analogy that makes it instantly clear
How domain names are structured in a strict tree hierarchy
What a Fully Qualified Domain Name (FQDN) is and why it matters
Who the key players are: registrar, DNS provider, nameserver, resolver
Why DNS uses UDP port 53 (and when it uses TCP)
The critical distinction between a domain registrar and a DNS provider

The Phone Book Analogy

Before smartphones, everyone had a physical phone book.

You didn't memorize your friend's number. You looked up their name and found the number listed next to it. The phone book was the middleman that translated a human-readable name into a machine-dialable number.

DNS is exactly that — but for the internet.

Phone Book	DNS
Person's name	Domain name (`google.com`)
Phone number	IP address (`142.250.80.46`)
The phone book itself	DNS records stored on nameservers
Calling directory assistance	Querying a recursive resolver

When you type google.com into your browser:

Your computer asks: "What is the IP address for google.com?"
DNS answers: 142.250.80.46
Your browser connects to that IP address
Google's homepage loads

Without DNS, you would need to memorize the IP address of every website you visit. That was manageable in 1983 when ARPANET had a few hundred hosts and used a flat text file called HOSTS.TXT. It became completely unmanageable as the internet grew to billions of domains.

Why DNS Exists

Computers communicate using IP addresses — numerical identifiers assigned to every device on a network.

IPv4 addresses look like this: 142.250.80.46 IPv6 addresses look like this: 2001:4860:4860::8888

Humans are not built to memorize strings of numbers, especially IPv6. We remember names.

DNS is the translation layer between how humans think (names) and how computers communicate (numbers). It is not an optional feature — it is foundational infrastructure. Every HTTP request, every API call, every email — virtually everything that crosses the internet starts with a DNS lookup.

Human types:    google.com
                    |
                   DNS
                    |
Computer uses:  142.250.80.46

Domain Hierarchy — The Tree Structure

DNS is organized as a distributed, hierarchical tree. Think of it like a file system — there is a root, then branches, then leaves. You read DNS names from right to left — the rightmost part is the highest level.

                        . (Root)
                        |
          .─────────────┼─────────────.
          |             |             |
        .com          .org           .io
          |             |             |
       google        wikipedia      github
          |                           |
   .──────┴──────.              .─────┴────.
   |             |              |          |
  www           mail           www        api
  (www.       (mail.         (www.      (api.
 google.com) google.com)   github.io) github.io)

Level 1 — Root (`.`)

The root is the very top of the DNS tree. It is represented by a single dot (.).

Every domain name technically ends with this dot: google.com. — but browsers and operating systems hide it from you. The root is managed by ICANN and served by 13 sets of root nameservers distributed globally (labeled A through M).

Level 2 — TLD (Top-Level Domain)

The TLD is the rightmost visible label — the part after the last dot.

Type	Examples	Notes
Generic TLD (gTLD)	`.com`, `.org`, `.net`, `.io`, `.app`	Open to anyone (mostly)
Country Code TLD (ccTLD)	`.us`, `.uk`, `.de`, `.jp`, `.au`	Assigned to countries
Sponsored TLD	`.gov`, `.edu`, `.mil`	Restricted, must qualify
New gTLD	`.cloud`, `.dev`, `.shop`, `.tech`	Introduced after 2012

TLDs are managed by registry operators (.com is managed by Verisign, .io by the Internet Computer Bureau, etc.).

Level 3 — Second-Level Domain (SLD)

This is the part you actually register and own. It sits directly to the left of the TLD.

 google  .com
 ──────   ───
   SLD    TLD

When you "buy a domain," you are registering a second-level domain with a registrar. Examples: google, amazon, github, yourname.

Level 4 — Subdomain

Subdomains appear to the left of the second-level domain. They are managed by whoever controls the domain — you do not need to register them separately.

 www    .google   .com
 ───     ──────    ───
 Sub       SLD     TLD

 mail   .google   .com
 ────    ──────    ───
 Sub       SLD     TLD

 api.v2 .example  .com
 ──────  ───────   ───
  Sub      SLD     TLD

Common subdomains:

Subdomain	Typical Use
`www`	Main website
`mail`	Email server
`api`	API endpoint
`docs`	Documentation
`blog`	Blog
`status`	Status page
`cdn`	Content delivery

Full Domain Breakdown Example

    api   .  v2   . example  .  com   .
    ───      ──     ───────     ───    ─
 subdomain subdomain  SLD       TLD  Root
 └─────────────────┘
      subdomains

Reading right to left: Root → .com (TLD) → example (SLD) → v2 (subdomain) → api (subdomain).

FQDN — Fully Qualified Domain Name

An FQDN is the complete, unambiguous domain name that identifies a specific host in the DNS hierarchy. It ends with a trailing dot representing the root.

mail.google.com.
────────────────
     FQDN
     (ends with root dot)

Without the trailing dot, a name is technically relative and could be interpreted differently depending on the DNS search domain configured on your machine. With the trailing dot, it is absolute — it always resolves the same way, regardless of local configuration.

In practice:

mail.google.com — what you type (relative, trailing dot implied)
mail.google.com. — the true FQDN (absolute, trailing dot explicit)

You will see FQDNs in DNS configuration files, SSL certificates, and server configurations. When a DNS tool like dig returns results, it shows the trailing dot explicitly.

$ dig mail.google.com

;; ANSWER SECTION:
mail.google.com.    21600  IN  A  142.250.112.17
                ^
           trailing dot shown by dig

Key Players in DNS

DNS is not a single server somewhere. It is a distributed system with distinct roles.

  You (Browser)
       |
       | "What's the IP for mail.google.com?"
       v
 ┌─────────────────────┐
 │  Recursive Resolver  │  ← does the legwork for you
 │  (8.8.8.8, 1.1.1.1) │
 └─────────┬───────────┘
           |
           | 1. Ask root nameserver
           v
 ┌─────────────────────┐
 │  Root Nameserver     │  ← "I don't know, ask .com TLD"
 │  (a.root-servers.net)│
 └─────────┬───────────┘
           |
           | 2. Ask .com TLD nameserver
           v
 ┌─────────────────────┐
 │  TLD Nameserver      │  ← "I don't know, ask Google's NS"
 │  (a.gtld-servers.net)│
 └─────────┬───────────┘
           |
           | 3. Ask Google's authoritative nameserver
           v
 ┌─────────────────────┐
 │  Authoritative NS    │  ← "Yes! The answer is 142.250.112.17"
 │  (ns1.google.com)    │
 └─────────────────────┘

Domain Registrar

The company where you purchase and register your domain name. Registrars are accredited by ICANN and have the right to sell second-level domains under various TLDs.

When you register a domain, the registrar:

Records your ownership in the TLD registry
Lets you configure which nameservers handle your domain's DNS

Examples: Namecheap, GoDaddy, Google Domains (now Squarespace), Porkbun, Hover

DNS Provider (DNS Hosting)

The company that hosts your DNS zone — meaning they operate the nameservers that hold your actual DNS records (A records, CNAME records, MX records, etc.).

Your DNS provider is whoever your nameservers point to. This is separate from your registrar.

Examples: Cloudflare (1.1.1.1), AWS Route 53, NS1, DNSimple, your registrar itself

Nameserver (NS)

A server that holds DNS records for a domain and responds to DNS queries about that domain. When you set up DNS hosting, you receive a set of nameserver addresses (e.g., ns1.cloudflare.com, ns2.cloudflare.com) and configure your registrar to point to them.

Recursive Resolver

Also called a recursive nameserver or full-service resolver. This is the server your computer contacts first when it needs to resolve a domain. It does the heavy lifting — querying root servers, TLD servers, and authoritative servers on your behalf — and caches the result.

Your recursive resolver is typically:

Your ISP's DNS server (default)
Google's public DNS: 8.8.8.8 / 8.8.4.4
Cloudflare's public DNS: 1.1.1.1 / 1.0.0.1
OpenDNS: 208.67.222.222

Authoritative Nameserver

The final authority for a domain's DNS records. When a recursive resolver eventually reaches the authoritative nameserver, it gets a definitive answer — not a cached one, not a referral, but the actual record.

Every domain has at least two authoritative nameservers (for redundancy). They hold the zone file — the full set of DNS records for that domain.

DNS is a Distributed, Hierarchical Database

This point deserves emphasis because it is a common misconception.

There is no single DNS server that knows everything. DNS is:

Distributed — the data is spread across thousands of servers worldwide
Hierarchical — organized in a tree, with each level only knowing about its portion
Delegated — each level delegates authority to the level below it

The root knows where TLD servers are. TLD servers know where authoritative nameservers are. Authoritative nameservers know the actual records. No single server holds the complete picture.

This design means:

No single point of failure
Scales to billions of domains
Each domain owner controls their own records
Updates propagate without a central coordinator

DNS Uses UDP Port 53

DNS queries and responses use UDP port 53 by default.

Why UDP?

DNS queries are small (typically under 512 bytes for a simple query)
UDP is connectionless — no handshake required
Speed matters: DNS latency directly adds to page load time
If a UDP response is lost, the client simply retries

When DNS uses TCP port 53:

The response is too large for a single UDP packet (over 512 bytes, or 4096 bytes with EDNS0)
Zone transfers (AXFR) — when a secondary nameserver copies all records from a primary nameserver
Some DNSSEC responses with large cryptographic signatures

Normal query:     DNS over UDP/53   ← fast, small, no handshake
Large response:   DNS over TCP/53   ← reliable, ordered, for big payloads
Zone transfer:    DNS over TCP/53   ← copying full zone file

This is why DNS is an example where knowing when to break the default rule (UDP → TCP) matters as much as knowing the default itself.

Common Mistakes

Confusing domain registrar with DNS provider. These are two separate services that can be provided by two completely different companies. You can register your domain at GoDaddy, then point your nameservers at Cloudflare to host your DNS. The registrar records ownership; the DNS provider serves the records. Many engineers assume they are the same because registrars often upsell their own DNS hosting.
Thinking there is one central DNS server. DNS is a distributed, hierarchical database. No single server holds all records. The system is designed with delegation at every level — root to TLD to authoritative nameserver. Centralization would be a catastrophic single point of failure for the entire internet.
Ignoring the trailing dot. mail.google.com and mail.google.com. are technically different notations. The trailing dot explicitly marks the domain as an FQDN — rooted at the DNS root. Without it, some DNS implementations may append a local search domain (e.g., resolving mail.google.com.internal.company.com). In DNS zone files and tools like dig, the trailing dot is always present and significant. Omitting it in a zone file can cause misconfiguration.

Interview Questions

1. What is DNS and why do we need it?

DNS (Domain Name System) is a distributed, hierarchical database that translates human-readable domain names (like google.com) into IP addresses (like 142.250.80.46) that computers use to route network traffic. We need it because humans cannot reasonably memorize IP addresses — especially with IPv6 — and because IP addresses can change over time while domain names remain stable. DNS decouples the name you remember from the underlying network address.

2. What is the difference between a domain registrar and a DNS provider?

A domain registrar is where you purchase and register ownership of a domain name. The registrar records your ownership with the TLD registry and lets you configure which nameservers are authoritative for your domain. A DNS provider hosts your DNS zone and operates the nameservers that actually answer queries about your domain. They are separate services: you could register at Namecheap but use Cloudflare as your DNS provider by updating your nameserver records at the registrar to point to Cloudflare's nameservers.

3. What is an FQDN?

An FQDN (Fully Qualified Domain Name) is the complete, absolute domain name for a host, ending with a trailing dot that represents the DNS root. For example, mail.google.com. is an FQDN. The trailing dot distinguishes it from a relative domain name and ensures it is resolved from the root of the DNS tree — not relative to any local search domain. FQDNs uniquely identify a host within the global DNS hierarchy.

4. What port does DNS use and why UDP instead of TCP?

DNS uses UDP port 53 for standard queries. UDP is chosen because DNS queries are small, latency-sensitive, and do not require the reliability overhead of TCP's three-way handshake. If a query is lost, the client simply retries — the cost is low. DNS falls back to TCP port 53 when responses exceed the UDP size limit (typically 512 bytes, or 4096 bytes with EDNS0 extensions), or when performing zone transfers (full replication of a DNS zone between nameservers).

Quick Reference — Cheat Sheet

Domain Hierarchy (ASCII Tree)

                          . (Root)
                          |
         .────────────────┼─────────────────.
         |                |                 |
       .com             .org              .io
         |                |                 |
      google          wikipedia           github
         |                                  |
  .──────┴──────.                     .─────┴──────.
  |             |                     |            |
 www           mail                  www           api
 │              │                     │             │
 www.google     mail.google           www.github    api.github
   .com           .com                  .io           .io

Reading direction: RIGHT → LEFT (TLD → SLD → Subdomain)

Full example breakdown:
  api.v2.example.com.
  ─── ── ─────── ─── ─
   │   │    │     │  │
   │   │    │     │  └── Root (the trailing dot)
   │   │    │     └───── TLD (.com)
   │   │    └─────────── SLD / domain (example)
   │   └──────────────── Subdomain (v2)
   └──────────────────── Subdomain (api)

Key DNS Players

Player	Who They Are	What They Do	Examples
Domain Registrar	Sells domain names	Records your ownership of a domain in the TLD registry; lets you set nameservers	Namecheap, GoDaddy, Porkbun
DNS Provider	Hosts your DNS zone	Operates nameservers that hold and serve your DNS records	Cloudflare, AWS Route 53, DNSimple
Nameserver (NS)	A server with DNS records	Holds the zone file; answers queries about your domain	ns1.cloudflare.com, ns1.google.com
Recursive Resolver	Your DNS "agent"	Queries root → TLD → authoritative servers on your behalf; caches results	8.8.8.8 (Google), 1.1.1.1 (Cloudflare)
Authoritative NS	The final authority	Holds the actual DNS records; gives definitive answers	ns1.google.com, ns1.amazonws.com
Root Nameserver	Top of the hierarchy	Knows where each TLD's nameservers are	a.root-servers.net through m.root-servers.net

DNS Transport

Scenario	Protocol	Port	Why
Standard query	UDP	53	Fast, small payload, no handshake needed
Large response (DNSSEC, etc.)	TCP	53	Reliable delivery for big packets
Zone transfer (AXFR)	TCP	53	Full zone file replication needs reliability

FQDN vs Relative Domain

mail.google.com     ← relative (trailing dot implied)
mail.google.com.    ← FQDN (trailing dot explicit, rooted at .)

Previous: Lesson 5.5 — Email Protocols (../ch05-application-protocols/05-email-protocols.md) Next: Lesson 6.2 — DNS Resolution (02-dns-resolution.md)

This is Lesson 6.1 of the Networking Interview Prep Course — 8 chapters, 32 lessons.

What is DNS?