0004 - DNS (Domain Name System)

Basic Concepts

• What is it? The “phonebook of the internet.” It’s a distributed database that translates human-readable domain names (www.google.com) into machine-readable IP addresses (142.250.191.78).
• Why is it needed? Because remembering IP addresses is hard for humans.

The DNS Resolution Process (Recursive Query)

What happens when you type google.com into your browser?

1. Browser/OS Cache: The browser first checks its own cache, then the OS cache. If the IP is found, the process stops here.
2. Recursive Resolver: The user’s computer (the “client” or “stub resolver”) sends a DNS query for www.google.com to its configured Recursive Resolver. This is typically the DNS server provided by your Internet Service Provider (ISP), like Airtel or Jio, or a public resolver like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1. The query from the client is recursive, meaning it asks the resolver: “Please find the full answer for www.google.com and give it to me.”
3. Root Servers:  The Recursive Resolver, having no cached entry for this domain, begins an iterative query process. It starts at the top. It sends a query to one of the 13 Root Server IP addresses.
   • Query: “What is the IP address for www.google.com?”
   • Root Server Response: “I do not know. But I can refer you to the TLD servers for .com. Here are their IP addresses.”
4. TLD (Top-Level Domain) Servers: The Recursive Resolver now uses the information from the Root Server. It picks one of the .com TLD Server IPs and sends it the same query.
   • Query: “What is the IP address for www.google.com?"
   • .com TLD Server Response: “I do not know the IP for the full domain. But I can refer you to the Authoritative Name Servers for the google.com domain. Their names are ns1.google.com, ns2.google.com, etc. Go ask them.”
5. Authoritative Name Server:  The TLD server responded with names (ns1.google.com), not IPs. If the resolver doesn’t already know the IP for ns1.google.com, it must perform another complete DNS lookup for ns1.google.com to get its IP address. This shows the recursive nature of DNS itself. Let’s assume for simplicity the resolver gets the IP for ns1.google.com. The Recursive Resolver now sends its query to the IP address of Google’s Authoritative Name Server (ns1.google.com).
   • Query: “What is the IP address for www.google.com?"
   • Authoritative Server Response: “I am the authority for google.com. The IP address for the www A record is 142.250.191.78. Here is your answer.”
6. Response to Client: The resolver passes the IP address back to your OS/browser. The resolver also caches this result for a certain period (defined by the TTL - Time to Live) so it can answer future requests for google.com instantly.**

Common DNS Record Types

• A Record: Maps a domain to an IPv4 address.
• AAAA Record: Maps a domain to an IPv6 address.
• CNAME (Canonical Name) Record: Maps a domain to another domain (an alias). E.g., www.example.com might be a CNAME for example.com.
• MX (Mail Exchange) Record: Specifies the mail servers for a domain.
• NS (Name Server) Record: Delegates a domain or subdomain to a set of authoritative name servers.
• TXT Record: Allows you to store arbitrary text. Used for things like domain ownership verification (e.g., SPF records for email).

Advanced DNS Concepts

• Round-Robin DNS: A simple form of load balancing. You can have multiple A records for the same domain, each with a different IP address. The DNS resolver will cycle through these addresses for different clients, distributing traffic across your servers.
• DNS Caching and TTL: The Time to Live (TTL) is a value in a DNS record that tells a resolver how long it is safe to cache that record. A low TTL means changes to DNS will propagate quickly, but it also means more queries to your name servers. A high TTL reduces load but makes updates slow. This trade-off is a classic senior-level discussion point.
• Anycast: A clever networking technique often used for DNS root servers and CDNs. The same IP address is announced from multiple locations around the world. User requests are automatically routed to the topologically nearest server, reducing latency and providing high availability.