How DNS Works: From Domain Name to IP Address

By Rahul — Google Frontend Engineer

Why Frontend Engineers Should Know DNS

DNS resolution happens BEFORE your page even starts loading. A slow DNS lookup adds 50-200ms to every new domain your page contacts. If your page uses 5 different domains (CDN, analytics, fonts, API, ads), that could be 1 second of DNS lookups.

The DNS Resolution Flow

When you type www.google.com in the browser:

Step 1: Browser Cache

Browser checks its own DNS cache first. Chrome keeps entries for about 60 seconds.

Step 2: OS Cache

If not in browser cache, the OS resolver checks its cache. Also checks the /etc/hosts file.

Step 3: Router Cache

Your home router often caches DNS responses too.

Step 4: ISP's Recursive Resolver

Your ISP's DNS server takes over. It performs a recursive lookup:

Step 5: Root Name Servers

The resolver asks a root server: "Where is .com?" The root server responds with the address of the .com TLD server. There are 13 root server clusters worldwide.

Step 6: TLD Name Servers

The resolver asks the .com TLD server: "Where is google.com?" It responds with Google's authoritative name servers.

Step 7: Authoritative Name Server

The resolver asks Google's name server: "What is the IP of www.google.com?" It responds with the IP address.

Step 8: Response and Caching

The IP is returned to the browser and cached at every level with a TTL (Time To Live).

DNS Record Types You Should Know

A     — Maps domain to IPv4 address (93.184.216.34)
AAAA  — Maps domain to IPv6 address
CNAME — Alias to another domain name
MX    — Mail server records
TXT   — Text records (used for domain verification, SPF)
NS    — Name server records

Performance Optimization

dns-prefetch

<!-- Tell browser to resolve DNS early -->
<link rel="dns-prefetch" href="//cdn.example.com" />
<link rel="dns-prefetch" href="//api.example.com" />
<link rel="dns-prefetch" href="//fonts.googleapis.com" />

This tells the browser to resolve DNS for these domains before they are needed. Saves 50-200ms per domain.

preconnect

Real Production Issues

• Low TTL during migration: When migrating servers, set TTL to 60 seconds a day before. After migration, some users will hit the old server until their cached DNS expires
• DNS propagation: Changes can take up to 48 hours to propagate globally. I have seen deployments fail because engineers assumed instant DNS updates
• Single point of failure: If your DNS provider goes down (like the 2016 Dyn attack), your entire site is unreachable. Use multiple DNS providers

Best Practices

• Use dns-prefetch for third-party domains
• Use preconnect for critical third-party origins
• Minimize the number of unique domains your page contacts
• Use a reliable DNS provider with global presence
• Set appropriate TTLs — not too long (hard to change) and not too short (too many lookups)

Summary

DNS translates domain names to IP addresses through a hierarchical system of caches and servers. As frontend engineers, we can optimize this with dns-prefetch and preconnect, and we should minimize the number of domains our pages depend on.