01-dns-deep-dive.md

🌐 Module 01: DNS (Domain Name System) Deep Dive

Core Focus: Resolution Process (Recursive vs Iterative), Hierarchy of DNS Servers, Record Types (A, AAAA, CNAME, MX, NS, TXT, SOA, PTR), Caching & TTL, DNSSEC, and Payment Gateway Architectural Impacts.


📑 Table of Contents

  1. What is DNS & Why is it Critical?
  2. The DNS Hierarchy & Server Types
  3. The Complete DNS Resolution Process
  4. Mastery of DNS Record Types
  5. DNS Caching Hierarchy & TTL Dynamics
  6. Security: DNS Poisoning, DoH, DoT, & DNSSEC
  7. Juspay & Payment Systems Real-World Context
  8. High-Yield Interview Questions & Verbatim Answers

1. What is DNS & Why is it Critical?

The Domain Name System (DNS) is the globally distributed, hierarchical database that translates human-readable domain names (e.g., api.juspay.in) into machine-routable IP addresses (e.g., 13.235.12.45 or 2404:6800:4009:81f::200e).

DNS TRANSLATION ┌───────────────────┐ ┌─────────────────────┐ │ api.juspay.in │ ──────────> │ 13.235.12.45 │ │ (Human-Friendly) │ │ (Network IP Layer) │ └───────────────────┘ └─────────────────────┘
  • Protocol & Port: Operates over UDP Port 53 for standard queries (low overhead, single packet request/response $\le 512$ bytes). Uses TCP Port 53 if response size exceeds 512 bytes (EDNS0), or during Zone Transfers (AXFR/IXFR) between primary and secondary nameservers.
  • Application Layer Protocol: Uses the underlying Transport layer (UDP/TCP) to exchange DNS messages.

2. The DNS Hierarchy & Server Types

DNS is organized as an inverted tree with the Root at the top:

. (Root Zone) ┌───────────────────┼───────────────────┐ .in .com .org (TLD Servers) ┌───────┴───────┐ │ │ juspay.in gov.in google.com wikipedia.org (2nd Level) │ │ api.juspay.in mail.google.com (Subdomains)

The 4 Crucial Server Types:

  1. DNS Recursive Resolver (Local / ISP / Public 8.8.8.8 / 1.1.1.1):
    • The "librarian" that fetches the answer for the client.
    • Accepts a recursive query from the client, queries the other servers iteratively, caches the response, and returns the final IP to the client.
  2. Root Name Server (. domain):
    • 13 logical root server addresses named [a-m].root-servers.net, managed by 12 distinct organizations (ICANN, NASA, Verisign, etc.).
    • Implemented via IP Anycast across hundreds of physical locations worldwide.
    • Directs the resolver to the appropriate TLD (Top-Level Domain) server based on extension (.in, .com, .io).
  3. TLD (Top-Level Domain) Name Server:
    • Manages records for specific domain extensions (.com, .in, .net, .org).
    • For example, Verisign operates .com, Registry.In operates .in.
    • Directs the resolver to the Authoritative Name Server for the specific domain (juspay.in).
  4. Authoritative Name Server:
    • The final authority holding the actual DNS record mappings (e.g., Route53, Cloudflare DNS, or company-hosted BIND server).
    • Returns the exact IP address (A/AAAA) or canonical alias (CNAME).

3. The Complete DNS Resolution Process

3.1 Recursive Query vs Iterative Query

┌────────────────────────────────────────────────────────────────────────────────────────┐ │ RECURSIVE vs ITERATIVE QUERY │ ├────────────────────────────────────────────────────────────────────────────────────────┤ │ RECURSIVE QUERY: │ │ "Find the exact IP for me and give me the final answer. If you don't know, you must go │ │ ask other servers until you find it." │ │ -> Sent by: Client (Browser/OS) to Recursive Resolver (e.g., ISP or 8.8.8.8). │ ├────────────────────────────────────────────────────────────────────────────────────────┤ │ ITERATIVE QUERY: │ │ "Give me the best answer you have right now. If you don't know the exact IP, give me │ │ the referral IP of the next nameserver I should ask." │ │ -> Sent by: Recursive Resolver to Root, TLD, and Authoritative Servers. │ └────────────────────────────────────────────────────────────────────────────────────────┘

3.2 Step-by-Step Resolution Trace

Suppose a user types https://api.juspay.in in their browser and no local caches exist:

[Browser / OS Client] │ 1. Recursive Query: "What is IP of api.juspay.in?" ▼ [Recursive Resolver (e.g., 8.8.8.8)] │ ├───── 2. Iterative: "Where is api.juspay.in?" ─────> [ Root Server '.' ] │ <─── 3. Referral: "Ask .in TLD at IP X.X.X.X" ───────┘ │ ├───── 4. Iterative: "Where is api.juspay.in?" ─────> [ .in TLD Server ] │ <─── 5. Referral: "Ask ns1.juspay.com at Y.Y.Y.Y" ──┘ │ ├───── 6. Iterative: "What is IP of api.juspay.in?" > [ Authoritative NS (ns1.juspay.com) ] │ <─── 7. Authoritative Answer: "13.235.12.45 (TTL=300)" ┘ │ ▼ 8. Final Answer Cached & Returned: 13.235.12.45 [Browser / OS Client]

Detailed Execution Sequence:

  1. Local Check: Browser checks internal DNS cache $\rightarrow$ OS checks hosts file and OS resolver cache.
  2. Recursive Request: OS sends a UDP packet to configured resolver (192.168.1.1 or 8.8.8.8) requesting api.juspay.in.
  3. Root Query: Resolver queries a Root Server (198.41.0.4). Root server replies: "I don't know api.juspay.in, but here are the IPs for the .in TLD servers".
  4. TLD Query: Resolver queries the .in TLD server. TLD server replies: "The authoritative nameservers for juspay.in are ns-123.awsdns.com".
  5. Authoritative Query: Resolver queries ns-123.awsdns.com. The authoritative server inspects its zone file and replies: "The A record for api.juspay.in is 13.235.12.45 with TTL 300 seconds".
  6. Return & Cache: Resolver saves the record in its local cache for 300s and delivers the IP to the client OS.
  7. Connection: Client initiates TCP 3-way handshake with 13.235.12.45:443.

4. Mastery of DNS Record Types

Record TypeNamePurposeExample Zone File Entry
AAddress RecordMaps hostname to IPv4 (32-bit)api.juspay.in. 300 IN A 13.235.12.45
AAAAIPv6 AddressMaps hostname to IPv6 (128-bit)api.juspay.in. 300 IN AAAA 2404:6800:4009::200e
CNAMECanonical NameMaps an alias hostname to another hostnamecheckout.juspay.in. 300 IN CNAME ingress.aws.juspay.net.
MXMail ExchangePoints to mail servers with priorityjuspay.in. 3600 IN MX 10 aspmx.l.google.com.
NSName ServerDelegated authoritative servers for the domainjuspay.in. 86400 IN NS ns-1.awsdns.com.
TXTText RecordArbitrary text (SPF, DKIM, DMARC, SSL verification)juspay.in. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
SOAStart of AuthorityZone metadata: primary NS, admin email, serial, timersjuspay.in. IN SOA ns1.juspay.com. admin.juspay.in. (2026083001 7200 3600 1209600 300)
PTRPointer RecordReverse DNS lookup (IP $\rightarrow$ Hostname)45.12.235.13.in-addr.arpa. 3600 IN PTR api.juspay.in.

4.1 A and AAAA Records

  • A Record (Address): Returns 32-bit IPv4 address. Used for 90%+ standard web traffic.
  • AAAA Record ("Quad-A"): Returns 128-bit IPv6 address (4 times larger than IPv4 $\rightarrow$ Quad A).

4.2 CNAME (Canonical Name) Record

A CNAME points a subdomain alias to another domain name, never directly to an IP address.

Query: checkout.merchant.com Step 1: Resolver gets CNAME: checkout.merchant.com -> secure-gateway.juspay.in Step 2: Resolver initiates fresh query for secure-gateway.juspay.in -> returns 13.235.12.45

[!CAUTION] The Critical CNAME Zone Apex Restriction (RFC 1912):
You cannot put a CNAME record on the Zone Apex / Root Domain (e.g., juspay.in or google.com).
Why? RFC rules state that if a CNAME exists for a node, no other records (NS, SOA, MX) can exist for that name. Because the root domain juspay.in must have NS and SOA records, placing a CNAME on juspay.in breaks DNS compliance.
Modern Solution: DNS providers use ALIAS (Route53) or CNAME Flattening (Cloudflare), which synthesize A records dynamically at the apex.


4.3 MX (Mail Exchange) Record

Directs emails to the correct mail server. Uses Priority Numbers (lower number = higher priority):

juspay.in. 3600 IN MX 5 mail-primary.juspay.in. juspay.in. 3600 IN MX 10 mail-backup.juspay.in.

If mail-primary is down or times out, sending SMTP servers fall back to priority 10.


4.4 NS (Name Server) Record

Delegates authority of a DNS zone to specific nameservers.

  • When you buy juspay.in from GoDaddy and host DNS on AWS Route53, you update the NS records at the registrar so the .in TLD knows which servers are authoritative for your zone.

4.5 TXT (Text) Record & Modern Uses

Originally designed for arbitrary human notes, TXT is now the backbone of internet security:

TXT RECORD USES │ ┌────────────────────────────────┼────────────────────────────────┐ ▼ ▼ ▼ SPF (Sender Policy) DKIM & DMARC Domain Verification Authorizes which mail Stores public key for Proves ownership to Google, servers can send email verifying email crypto SSL CAs (Let's Encrypt), for domain (anti-spoofing). signatures. or payment gateways.
  • Example SPF Record: juspay.in. TXT "v=spf1 include:_spf.google.com ip4:13.235.12.0/24 -all" (Tells receiving mail servers to reject any emails claiming to be from @juspay.in if not sent by Google or Juspay's AWS subnet).

4.6 SOA & PTR Records

  • SOA (Start of Authority): Contains zone serial number (incremented on edits so secondaries know to sync), refresh interval, retry interval, and minimum TTL (used for negative caching).
  • PTR (Pointer): Used in Reverse DNS (rDNS) to map an IP address back to a hostname. Used heavily by email spam filters to verify that an SMTP server's IP matches its claimed hostname.

5. DNS Caching Hierarchy & TTL Dynamics

DNS resolution incurs latency (50ms–200ms without cache). To optimize this, caching happens at multiple layers:

┌──────────────────────────────────────────────────────────┐ │ 1. Browser Cache (Chrome: chrome://net-internals/#dns) │ ~1 minute ├──────────────────────────────────────────────────────────┤ │ 2. OS Resolver Cache (flush via: ipconfig /flushdns) │ Configurable ├──────────────────────────────────────────────────────────┤ │ 3. Router / Gateway Cache (Home / Office WiFi Router) │ Respects TTL ├──────────────────────────────────────────────────────────┤ │ 4. Recursive Resolver Cache (ISP / 8.8.8.8 / 1.1.1.1) │ Respects TTL └──────────────────────────────────────────────────────────┘

Understanding TTL (Time-To-Live):

  • TTL: An integer in seconds defined in the DNS record specifying how long resolvers and clients may cache the answer.
  • Trade-off Matrix:
    TTL ValueProsConsIdeal For
    High TTL (86400s / 24h)Lower latency, reduces query load on nameservers, immune to transient NS outagesSlow migration; IP changes take 24h to propagate globallyStatic sites, MX records, root NS
    Low TTL (60s – 300s)Fast zero-downtime failovers, quick blue-green routing changesHigh query volume, slight latency increase on cache missPayment APIs, microservice load balancers

6. Security: DNS Poisoning, DoH, DoT, & DNSSEC

TRADITIONAL DNS vs SECURE EXTENSIONS ┌───────────────────────┬────────────────────────────────────────────────────────┐ │ Threat / Limitation │ Solution │ ├───────────────────────┼────────────────────────────────────────────────────────┤ │ DNS Cache Poisoning │ DNSSEC (Cryptographic signatures on DNS records) │ │ Eavesdropping / ISP │ DoH (DNS over HTTPS / Port 443) or DoT (Port 853) │ │ DNS Amplification DDoS│ Response Rate Limiting (RRL) + Anycast Distribution │ └───────────────────────┴────────────────────────────────────────────────────────┘

1. DNS Cache Poisoning (Kaminsky Attack)

An attacker injects forged IP records into a recursive resolver's cache before the legitimate authoritative server responds. Clients querying the resolver are redirected to a phishing server.

  • Mitigation: Source Port Randomization (using all 16-bit UDP ports rather than fixed port 53) + DNSSEC.

2. DNSSEC (DNS Security Extensions)

Adds cryptographic authenticity to DNS records.

  • Uses public/private key cryptography (RRSIG, DNSKEY, DS records).
  • Builds a Chain of Trust from the Root Zone down to the domain, verifying that DNS responses have not been forged or tampered in transit.

3. DoH (DNS over HTTPS) vs DoT (DNS over TLS)

  • Traditional DNS: Sent in plaintext over UDP 53 $\rightarrow$ anyone on the local network/ISP can see what domains you visit.
  • DoH: Wraps DNS queries in encrypted HTTP/2 or HTTP/3 traffic on standard Port 443 (indistinguishable from normal HTTPS web traffic).
  • DoT: Uses dedicated Port 853 with TLS encryption.

7. Juspay & Payment Systems Real-World Context

JUSPAY DNS ROUTING ARCHITECTURE [ Client / SDK ] │ DNS Query: api.juspay.in (Latency-Based Anycast) │ ┌──────────────────────┴──────────────────────┐ ▼ ▼ [ Mumbai AWS Region ] [ Hyderabad AWS Region ] Latency: ~8ms for West India Latency: ~12ms for South India
  1. Geo-DNS & Latency-Based Routing:
    • Juspay uses Route53 Latency-Based Routing and Anycast DNS so incoming payment requests from merchant apps hit the physically closest payment cluster, shaving 20-40ms off transaction processing time.
  2. Zero-Downtime Migration via TTL Pre-Warming:
    • When migrating payment ingress infrastructure, DevOps drops the DNS TTL from 3600 to 60 seconds 48 hours in advance. When the switch happens, traffic moves to the new cluster within 1 minute with near-zero stale requests.
  3. Third-Party Bank Health Failover:
    • Dynamic DNS / Health-Check DNS routing enables redirecting traffic away from degraded bank payment gateways to healthy backup acquirers.

8. High-Yield Interview Questions & Verbatim Answers

Q1: "Walk me through what happens when a user requests https://api.juspay.in from a DNS perspective."

Spoken Answer:
"First, the browser checks its local DNS cache, followed by the OS cache and hosts file. If not found, the OS makes a recursive query over UDP port 53 to the configured resolver, such as 8.8.8.8.
The resolver then performs a series of iterative queries:

  1. It asks a Root Server, which refers it to the .in TLD server.
  2. It queries the .in TLD server, which returns the authoritative nameservers for juspay.in (e.g., AWS Route53).
  3. It queries the Authoritative Name Server, which returns the A record containing the IPv4 address 13.235.12.45 and a TTL.
    The resolver caches this mapping and returns the IP to the OS, which delivers it to the browser to initiate the TCP 3-way handshake."

Q2: "What is the difference between an A record and a CNAME record? Can you put a CNAME on juspay.in?"

Spoken Answer:
"An A record maps a domain name directly to an IPv4 address, whereas a CNAME record maps an alias hostname to another canonical hostname (requiring a secondary DNS lookup to resolve the final IP).
No, by RFC 1912 specifications, you cannot place a CNAME record at the Zone Apex / Root (juspay.in). If a CNAME exists for a node, no other records can exist for that name. Because the root domain requires NS and SOA records, a CNAME at the apex violates DNS protocol. To work around this, modern DNS providers use proprietary features like ALIAS or CNAME Flattening."


Q3: "What are the common DNS record types and what are their primary purposes?"

Spoken Answer:
"The core DNS records are:

  • A: Resolves hostname to IPv4 address.
  • AAAA: Resolves hostname to IPv6 address (128-bit).
  • CNAME: Hostname alias pointing to another hostname.
  • MX: Directs domain emails to designated mail servers with priority weighting.
  • NS: Specifies the authoritative nameservers for the DNS zone.
  • TXT: Holds arbitrary text, used for email security (SPF, DKIM, DMARC) and domain ownership verification.
  • SOA: Stores core zone administrative metadata and sync serial numbers.
  • PTR: Maps IP addresses back to domain names for reverse DNS lookups."

Q4: "Why does DNS use UDP by default instead of TCP? When does it switch to TCP?"

Spoken Answer:
"DNS uses UDP port 53 by default because DNS lookups require speed and low latency. UDP avoids the 3-way handshake and connection teardown overhead, fitting the request and response in single, lightweight packets.
DNS switches to TCP port 53 in two cases:

  1. When the response payload exceeds 512 bytes (or the negotiated EDNS0 buffer size), indicated by the TC (Truncated) bit being set, forcing the client to retry over TCP.
  2. During Zone Transfers (AXFR/IXFR) between master and slave nameservers, where guaranteed delivery and data integrity are mandatory."