What is DNS?
Computers talk in IP addresses (192.168.1.1). Humans talk in domain names (google.com).
DNS (Domain Name System) maps human-readable names to IP addresses.
It is a distributed, hierarchical database. There is no single server that knows every domain name.
The Hierarchy
A query for www.example.com. (note the trailing dot) traverses a tree structure.
graph TD
Root[Root Servers `. `] --> TLD[TLD Servers `.com`]
TLD --> Auth[Authoritative NS `example.com`]
Auth --> Record[IP: 1.2.3.4]
1. Root Servers (.)
- There are 13 logical root server IP addresses (A-M).
- Managed by organizations like NASA, Verisign, ICANN.
- They know where the TLD Servers live.
2. TLD Servers (.com, .org, .io)
- Top-Level Domain servers.
- The
.comTLD servers know which Name Servers are responsible forgoogle.comoramazon.com.
3. Authoritative Name Servers
- The final destination. These hold the actual DNS records (A, CNAME, MX).
- Controlled by Domain Registrars (GoDaddy) or Cloud Providers (AWS Route 53).
DNS Resolution Flow
What happens when you type google.com?
Interactive: Recursive Lookup Flow
Recursive DNS Lookup
- Browser Cache: Checks chrome://net-internals/. "Have I been here recently?"
- OS Cache: Checks
/etc/hostsor Windows Registry. - Recursive Resolver (ISP): Your computer asks your ISP (or 8.8.8.8).
- If Resolver has it cached -> Returns IP.
- If NOT cached -> Resolver performs the Recursive Query.
The Recursive Dance
If the Resolver (8.8.8.8) knows nothing:
- Resolver -> Root: "Where is .com?"
- Root: "I don't know IP, but here are the .com TLD servers."
- Resolver -> TLD: "Where is google.com?"
- TLD: "I don't know IP, but GoDaddy NS1 runs google.com."
- Resolver -> Authoritative (NS1): "What is IP of google.com?"
- NS1: "It is 142.250.190.46."
- Resolver -> You: "Here is the IP." (And Caches it for TTL seconds).
Key Concepts
Record Types
- A: Maps name to IPv4 (
1.2.3.4). - AAAA: Maps name to IPv6 (
2001:db8::1). - CNAME: Alias. Maps name to another name (
www.google.com->google.com). - MX: Mail Exchange. Where to route emails.
- TXT: Text. Used for verification (SPF, DKIM, Google Search Console).
Time To Live (TTL)
How long (in seconds) a Resolver should cache the record.
- High TTL (24h): Less traffic to authoritative servers. Updates take 24h to propagate. (Good for stable APIs).
- Low TTL (60s): High traffic. Fast failover. (Good for Load Balancing).
Anycast Routing
How do 13 Root IPs serve billions of users? Anycast. Multiple servers around the world announce the same IP address via BGP. The network routes your request to the geographically closest server.
Code Example: Querying DNS
import dns.resolver
# 1. Simple lookup
def lookup_ip(domain):
try:
answers = dns.resolver.resolve(domain, 'A')
for rdata in answers:
print(f"IP: {rdata.address}")
except Exception as e:
print(f"Lookup failed: {e}")
# 2. Get Name Servers (NS)
def get_nameservers(domain):
answers = dns.resolver.resolve(domain, 'NS')
for r in answers:
print(f"NS: {r.target}")
# Usage
# lookup_ip("google.com")
# get_nameservers("google.com")
Interview Tips š”
- "What happens when you type URL in browser?" ā DNS is step 1. Mention Caching hierarchy!
- "Recursive vs Iterative?" ā Your computer makes a Recursive request (Get me the answer). The ISP makes Iterative requests (I'll ask Root, then TLD...).
- "CNAME chasing" ā A CNAME requires a second lookup (first to get CNAME target, second to get A record). Slight performance penalty.
- "Geo-DNS" ā Route 53 can return different IPs based on user location (Latency-based routing).
Related Concepts
- Load Balancing (DNS Round Robin)
- CDN Architecture (Uses CNAME/Anycast)
- HTTP Interaction
About ScaleWiki
ScaleWiki is an interactive educational platform dedicated to demystifying distributed systems, software architecture, and system design. Our mission is to provide high-quality, technically accurate resources for software engineers preparing for interviews or solving complex scaling challenges in production.
Read more about our Editorial Guidelines & Authorship.
Educational Disclaimer: The architectural patterns and system designs discussed in this article are based on common industry practices, technical whitepapers, and public engineering blogs. Actual implementations in enterprise environments may vary significantly based on specific product requirements, legacy constraints, and evolving technologies.
Related Articles
HTTP Evolution (H1 to H3)
From text-based HTTP/1.1 to binary HTTP/2 and UDP-based HTTP/3 (QUIC). Why we needed upgrades and how they solve Head-of-Line Blocking.
Proxies: Forward vs Reverse
Understanding proxy servers that act as intermediaries between clients and servers, including forward proxies for client anonymity and reverse proxies for load balancing, security, and caching.
Service Discovery
Complete guide to microservice discovery in dynamic cloud environments, covering client-side vs server-side patterns, health checks, DNS-based discovery, and production implementations using Consul, etcd, Eureka, and Kubernetes services.