How DNS Works — The Internet's Phone Book Explained

Every request starts with DNS#

You type codelit.io in your browser. Before anything else happens — before the HTML loads, before the API calls, before the JavaScript runs — your browser needs to figure out which server to talk to.

That's DNS. Domain Name System. It translates human-readable names into IP addresses.

The lookup chain#

When your browser needs to resolve codelit.io, it checks multiple caches before hitting the network:

1. Browser cache#

Your browser remembers recent lookups. If you visited codelit.io five minutes ago, the IP is already cached. Lookup time: 0ms.

2. OS cache#

The operating system maintains its own DNS cache. Even if the browser cache is empty, the OS might have it from another app. Lookup time: 0ms.

3. Router cache#

Your home router caches DNS responses for all devices on the network. Lookup time: ~1ms.

4. ISP recursive resolver#

Your ISP runs DNS servers that cache popular domains. For a site like google.com, the answer is almost always cached here. Lookup time: ~5-20ms.

5. Root → TLD → Authoritative#

If nobody has the answer cached, the full resolution happens:

Recursive Resolver → Root Server (.): "Who handles .io?"
Root Server → TLD Server (.io): "Who handles codelit.io?"
TLD Server → Authoritative NS: "codelit.io is at 76.76.21.21"

Lookup time: ~50-200ms (only happens once, then cached).

DNS record types#

TTL: the caching timer#

Every DNS record has a TTL (Time to Live) — how long resolvers should cache it.

• Short TTL (60s): Changes propagate fast. Good for failover. More DNS queries.
• Long TTL (86400s): Fewer queries. Faster for users. Slower to update.

Best practice: Use 300-3600s for most records. Use short TTL (60s) when you're about to make changes, then increase after.

CDN and DNS#

CDNs like Cloudflare and Vercel use DNS to route users to the nearest edge server:

1. User in Tokyo resolves codelit.io
2. Cloudflare's DNS returns the IP of a server in Tokyo
3. User in New York gets the IP of a server in Virginia

This is called GeoDNS or Anycast DNS — same domain, different IPs based on location.

DNS in system design#

DNS matters for system design in several ways:

Load balancing: DNS can return multiple IPs (round-robin) to distribute traffic.

Failover: Health-checked DNS removes unhealthy servers automatically.

Blue-green deploys: Point DNS to the new environment, switch back if there's a problem.

Service discovery: Internal DNS resolves service names to pod IPs in Kubernetes.

Common DNS issues#

DNS propagation delay. You changed your DNS records, but users still see the old IP. This isn't "propagation" — it's caches holding the old TTL. Wait for the TTL to expire.

DNS as a single point of failure. If your DNS provider goes down, nothing works. Use multiple NS providers or a provider with global anycast (Cloudflare, Route53).

DNS amplification attacks. Attackers use DNS to amplify DDoS traffic. Mitigate with rate limiting and DNSSEC.

See the full request path#

On Codelit, generate any web application and you'll see DNS, CDN, load balancers, and API servers in the data flow. Click any component to understand how requests travel from the user's browser to your database and back.

---

Trace the full request path: describe your system on Codelit.io and see how DNS, CDN, and load balancers connect.