DNS: The Internet’s Phonebook

By the end of this lesson you will be able to

• Explain why DNS exists and read any domain name as a path through the DNS tree.
• Name the four kinds of DNS server and say exactly what each one knows and answers.
• Walk through a full lookup step by step, and recognise the shortcuts (cache hits) and failures (NXDOMAIN, timeouts, SERVFAIL).
• Choose the right record type: A, AAAA, CNAME, MX, TXT, NS, plus PTR and SOA.
• Use TTL deliberately: caching layers, safe IP migrations, and why “DNS propagation” is really cache expiry.
• Explain DoH/DoT and DNSSEC, and how system designers use DNS for geo-routing and failover.
• Design split-horizon (private) DNS, where one name gets a different answer inside and outside a network, and use DNS for service discovery without being caught out by caches.

#Why DNS exists

Computers on a network find each other by IP address, for example 142.250.190.46 (IPv4) or 2001:db8::1 (IPv6). Routers forward packets by looking at the destination IP; they have no idea what “google.com” means.

People, on the other hand, cannot remember thousands of number strings. The Domain Name System (DNS) solves this: it turns a human-friendly name like google.com into the IP address a computer needs. That is why it is often called the phonebook of the internet.

DNS does more than map names to IPs:

• One name can have many addresses. Big sites return different IPs to different users to spread load and send people to a nearby data centre.
• Addresses can change without anyone noticing. If a company moves its website to a new server, it updates DNS and users keep typing the same name.
• A name holds other information too: which server receives email for a domain (MX), aliases (CNAME), proofs of ownership and email-security policies (TXT), and more.

#Reading a domain name: the DNS tree

DNS is not one giant list on one computer. It is a hierarchy, an upside-down tree, and every domain name is a path through it, read from right to left.

Take www.example.com. (the trailing dot is normally invisible, but it is really there):

A name written all the way to the root, like www.example.com., is called a Fully Qualified Domain Name (FQDN).

TLDs come in two main kinds:

• gTLD (generic): .com, .org, .net, .dev, .app…
• ccTLD (country code): .bd, .uk, .in. Many countries add their own second level, so a Bangladeshi company might be shop.com.bd.

#The four kinds of DNS server

A lookup is handled by four kinds of server working together. Each knows only its own part of the tree.

1. 1. Recursive resolver: the assistant who does all the work

   Your device sends its question to one recursive resolver and waits. The resolver does the legwork: it asks the other three kinds of server one by one, collects the final IP address and hands it back. It also keeps a large cache of recent answers.

   Usually it is your ISP’s resolver (Link3, Grameenphone…), handed to your device automatically by DHCP. Many people switch to a public resolver instead: Google 8.8.8.8, Cloudflare 1.1.1.1 or Quad9 9.9.9.9.

   Your operating system has a tiny helper called the stub resolver. It cannot walk the tree itself; it only forwards questions to the recursive resolver and caches the answers.

2. 2. Root name server: the main directory

   The root servers sit at the top of the hierarchy. They do not know the IP of any website. They know only one thing: which servers are responsible for each TLD (.com, .org, .bd…).

   There are 13 named root server identities, a.root-servers.net to m.root-servers.net, run by 12 organisations. Each identity is not one machine: thanks to anycast, the same IP address is announced from many locations, so there are well over a thousand root server instances worldwide, including in Bangladesh. Your query goes to the nearest one.

3. 3. TLD name server: the specialised section

   Each TLD has its own servers. The .com TLD servers know, for every .com domain, which authoritative name servers its owner registered. They still do not know the website’s IP.

4. 4. Authoritative name server: the original record book

   This is the last stop. The authoritative server for a domain (for example ns1.example.com, or Cloudflare’s servers if Cloudflare hosts your DNS) holds the actual records: A, AAAA, MX, TXT and the rest. Its answer is final and correct, which is why it is called authoritative. Every other server only repeats or caches it.

   Each domain normally has at least two authoritative servers in different networks, so one failure does not take the domain offline.

#A complete lookup, step by step

Here is what happens in the milliseconds after you type example.com and press Enter. Play each scenario: the first one is the full journey, the rest are the variations you meet every day.

The search always starts at home. It helps to see two phases: a local cache journey (browser, operating system, home router, then the recursive resolver’s cache), which answers the vast majority of lookups, and a global search (root → TLD → authoritative), which happens only when no cache on the way has a fresh copy. On the way back the answer is stored in every cache it passes, for as long as its TTL allows.

In words, the cold-cache case:

1. User request. You type example.com in the browser.
2. Local cache check. The browser checks its DNS cache, then the operating system checks its own cache and the hosts file. If nothing is found, the OS sends the question to the recursive resolver.
3. Query to a root server. The resolver asks: “Where can I find example.com?”
4. Root response. “I don’t know example.com, but here are the .com TLD servers. Ask them.” This kind of answer is called a referral.
5. Query to the TLD server. The resolver asks a .com server.
6. TLD response. “I don’t have the IP, but example.com’s authoritative name servers are ns1/ns2.example.com. Knock on their door.”
7. Query to the authoritative server. The resolver asks ns1.example.com.
8. Final answer. “The IPv4 address of example.com is 203.0.113.10, and you may cache it for 3600 seconds.”
9. Caching and delivery. The resolver stores the answer in its cache and returns it to your device, which caches it too. The browser now opens an HTTP/HTTPS connection to that IP and the page loads.

#Recursive vs iterative queries

The two kinds of question in that flow behave differently:

• Recursive query (your device → resolver): “Get me the final answer, whatever it takes.” The resolver must return either the answer or an error.
• Iterative query (resolver → root, TLD, authoritative): “Tell me what you know.” Each server answers from its own knowledge, either with the answer or with a referral to a server closer to it. The resolver follows the referrals itself.

#How DNS travels on the wire

• Classic DNS uses UDP port 53: one small question packet, one answer packet, no handshake. That makes it very fast.
• If an answer is too big for a UDP packet (common with DNSSEC), the server sets a “truncated” flag and the resolver retries over TCP port 53. Copying a whole zone between servers (a zone transfer) always uses TCP.
• Because UDP has no connection, a lost packet is simply not answered. The resolver handles this with timeouts and retries, often against a different name server.

#DNS record types

A DNS server stores much more than IP addresses. Each piece of data is a record with a type, a name, a value and a TTL.

A few rules that trip people up:

• A CNAME cannot sit next to other records with the same name. That is why you cannot put a CNAME on the bare domain (example.com, called the zone apex), which must have NS and SOA records. Many DNS hosts offer a workaround called ALIAS, ANAME or “CNAME flattening”.
• MX and CNAME values are names, not IPs. The sender must look up the A/AAAA record of the mail server next.
• A name can have several records of the same type, for example two A records for load spreading, or two MX records for backup.

Here is an MX record doing its job, including what happens when the main mail server is down:

#TTL and caching

If every website visit meant travelling to four servers around the world, the internet would be slow and the authoritative servers would be crushed. The fix is caching, controlled by the TTL.

#What TTL means

TTL (Time To Live) is a number of seconds attached to every DNS record. It tells resolvers and browsers: “You may keep this record in your cache for this long.”

If a record has TTL = 3600, every browser and resolver may cache it for 1 hour. After that the copy is deleted and the next request fetches a fresh one from the authoritative server.

Typical values:

A resolver hands out the remaining TTL. If it cached a record 20 minutes ago with TTL 3600, it tells you TTL 2400, so every downstream cache expires at the same moment.

#The four layers of DNS cache

Answers are cached at four layers, and the lookup stops at the first layer that has a fresh copy:

1. Browser cache: Chrome and Firefox remember recently visited names for a short time.
2. OS cache and hosts file: if the browser has nothing, the operating system checks its memory and the hosts file, a local text file that overrides DNS for the names listed in it.
3. Router cache: many home Wi-Fi routers act as a small DNS forwarder: DHCP tells your devices to use the router as their DNS server, and the router caches answers for every device on the network. A router that simply hands out the ISP’s resolver address caches nothing.
4. ISP / resolver cache: your recursive resolver (usually the ISP’s, or a public one such as 1.1.1.1 if you changed it) has a huge cache shared by thousands of customers, so popular names are almost always already there.

#Changing a record safely

That last point is the most practical thing to know about TTL. Watch what happens when a site moves to a new server, done wrong and done right:

The safe recipe for moving a service to a new IP:

1. Lower the TTL in advance, for example from 86400 to 300, while keeping the old IP.
2. Wait at least the old TTL so every cache picks up the short one.
3. Switch the record to the new IP. Within about 5 minutes everyone follows.
4. Keep the old server running for a while for stragglers, then raise the TTL again.

#Negative caching

“Not found” answers are cached too. When a name does not exist, the server returns NXDOMAIN, and resolvers cache that answer for the time given in the zone’s SOA record. So if you create a new subdomain right after someone (or you) looked it up, people may keep getting “not found” until that negative cache expires.

#DNS security and privacy

DNS was designed in the 1980s with no security at all. Three problems and their fixes:

#DNS in system design

Because every client asks DNS before connecting, DNS is the very first point where a large system can steer traffic.

• Geo / latency-based routing (GeoDNS): answer each user with the IP of the nearest or fastest region. Services like AWS Route 53 and Cloudflare do this.
• Health-checked failover: stop handing out a region that fails health checks. This needs short TTLs, because clients holding the old answer keep using it until it expires.
• Round-robin DNS: several A records for one name, rotated on each answer. It is cheap but blind: no load awareness, and without health checks it keeps returning dead servers. Usually DNS points to a load balancer and the load balancer spreads the traffic.
• Anycast: the same IP announced from many locations (how root servers, 1.1.1.1 and CDNs work), so routing itself delivers users to the nearest site.
• DNS is a dependency: if your DNS provider goes down, your perfectly healthy servers become unreachable by name. Large companies use two DNS providers for this reason.

#Split-horizon and private DNS

Often one name should mean two different things depending on who asks. Inside the office or the cloud network, app.example.com should be the private address 10.0.1.20; on the internet it should be the public load balancer 203.0.113.10. And names such as db.internal.example.com should exist only inside. This is split-horizon DNS (also called split-brain or split DNS): the same zone is served as two views, and the answer depends on which resolver you ask.

Why companies do it:

• Inside clients take the short, private path: no NAT, no hairpinning through the public address (lesson 1.7), no load balancer or egress cost in between.
• Internal names stay internal: outsiders cannot even list which hosts exist inside.
• The public zone stays small: it holds only what the internet needs.

How it is built:

• On-premises: the internal DNS servers (for example the ones that come with Windows Active Directory) hold the inside copy; the public DNS host holds the outside copy. Many DNS servers can also serve both views themselves, choosing by the client’s address.
• In the cloud: a private hosted zone (AWS Route 53, Google Cloud DNS, Azure Private DNS) is attached to one or more VPCs. Every VPC has a built-in VPC resolver (in AWS at the network’s base address plus two, such as 10.0.0.2) that answers from the private zone first and from public DNS otherwise. Private endpoints for cloud services use the same trick: the service’s usual name resolves to a private IP inside your VPC.
• Hybrid: offices and cloud networks forward each other’s internal domains with conditional forwarding (“questions about internal.example.com go to 10.0.0.2”).

What goes wrong:

• A VPN with the wrong resolver. The tunnel works, but DNS still goes to an outside resolver: public names get the public answer, internal names get NXDOMAIN. The fix is split DNS on the VPN: queries for your internal domains go through the tunnel to the internal resolver.
• A stale inside answer. A laptop leaves the office with a private address cached and cannot reach the service until the TTL runs out. Keep TTLs on split names short.
• The views drift apart. Someone adds a record to one view and forgets the other, and the service works only for half the users. Keep both views in code and review them together.
• Using a name you do not own. Internal names under made-up domains (corp.com, .local, invented top-level domains) collide with real ones or with local-network discovery. Use a subdomain of your own domain such as internal.example.com; in 2024 ICANN also reserved .internal for private use.

#DNS-based service discovery

In a system of many services, instances start, stop and move all the time, so hard-coded IP addresses break. Service discovery lets one service find the current, healthy instances of another by name, and DNS is the oldest and most universal way to do it:

• Each instance registers with a registry when it starts (Consul, Kubernetes, AWS Cloud Map), and the registry health-checks it.
• A client resolves a name such as payments.service.consul and gets the addresses of healthy instances only.
• SRV records add what an A record cannot: the port, plus a priority and a weight (_payments._tcp.example.com SRV 1 1 8443 p1.example.com). That matters when containers share hosts on different ports.
• TTLs are seconds, sometimes zero, because the list changes constantly.
• Kubernetes adds a twist: a normal service name such as payments.shop.svc.cluster.local resolves to one stable virtual IP, and proxy rules on each node spread connections across the healthy pods. Pods come and go without DNS changing at all. A headless service returns the pod addresses directly instead.

The weak point is the one you already know: caches. Removing a dead instance from DNS changes only future answers; a client that cached the old list keeps calling the dead address until the TTL ends, and a runtime that ignores TTLs keeps it until restart. Long-lived connections (HTTP/2, gRPC) stay on the old instances until they reconnect. So clients must retry another address on failure, and large systems often add libraries or a service mesh that watch the registry directly and react in under a second, with DNS as the lowest common denominator.

#Try it yourself

You can watch DNS directly from a terminal:

# Windows, macOS, Linux: ask your configured resolver
nslookup example.com

# Ask a specific resolver (Cloudflare) for the MX records
nslookup -type=mx gmail.com 1.1.1.1

# macOS / Linux: detailed answer with TTLs
dig example.com A
dig +trace example.com     # walk root → TLD → authoritative yourself

# Windows: see and clear the OS DNS cache
ipconfig /displaydns
ipconfig /flushdns

In dig output, look at the ANSWER SECTION: the number before IN A is the remaining TTL. Run the same command twice and watch it count down: that is a cache hit at your resolver.

#Summary

Key takeaways

• DNS turns names into IP addresses (and stores mail servers, aliases, verification text and more). It is a hierarchy, read right to left: root → TLD → domain → host.
• Four kinds of server: the recursive resolver does the work for you; root servers point to TLDs; TLD servers point to a domain’s name servers; authoritative servers hold the real records.
• A full lookup is one recursive query from your device plus iterative queries by the resolver, but most lookups are answered from a cache (browser, OS/hosts file, router, resolver).
• Key records: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail, by priority), TXT (SPF/DKIM/verification), NS (who is authoritative), plus PTR and SOA.
• TTL controls how long answers are cached. Lower it before changing a record; “propagation” is just caches expiring. “Not found” is cached too.
• Failures you will meet: NXDOMAIN (name does not exist), timeouts with retry to the next name server, SERVFAIL when no valid answer can be obtained.
• DoH/DoT encrypt queries; DNSSEC proves authenticity. In system design, DNS steers users by geography, health and round-robin, with TTL as the speed-versus-load trade-off.
• Split-horizon DNS gives inside and outside clients different answers for the same name (private hosted zones, the VPC resolver); VPN clients need the internal resolver. Service discovery uses DNS names, short TTLs and SRV records; cached answers are its weak point, so clients retry.

Self-check: DNS30 questions