DNS — The Internet’s Phone Book
DNS (Domain Name System) translates human-readable names (api.example.com) to IP addresses. It’s a globally distributed, hierarchically organised database.
Resolution Walk
Browser: "What's the IP of api.example.com?"
→ OS: check /etc/hosts, then local resolver cache
→ Recursive resolver (e.g. 8.8.8.8):
→ Root nameserver: "I don't know, ask .com TLD"
→ .com TLD nameserver: "I don't know, ask example.com's NS"
→ example.com nameserver: "api.example.com → 93.184.216.34"
→ Cache with TTL, return to browser
The recursive resolver (usually your ISP’s or a public resolver like Cloudflare 1.1.1.1) does the heavy lifting. Most lookups are served from cache — the authoritative walk only happens on cache miss or TTL expiry.
Key Record Types
| Type | Purpose | Example |
|---|---|---|
| A | IPv4 address | api.example.com → 93.184.216.34 |
| AAAA | IPv6 address | api.example.com → 2606:2800::1 |
| CNAME | Canonical name alias | www → example.com |
| MX | Mail exchange | example.com → mail.example.com |
| TXT | Arbitrary text (SPF, DKIM, verification) | |
| NS | Nameserver delegation | example.com → ns1.example.com |
TTL matters: low TTL (60s) = expensive, fast-updating. High TTL (86400s) = cheap, slow propagation. CDNs use low TTLs for failover; stable services use high TTLs.
DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT)
Traditional DNS is plaintext UDP on port 53 — your ISP (and anyone on the path) can see every hostname you resolve. DoH wraps DNS queries in HTTPS (port 443), making them indistinguishable from web traffic. DoT uses TLS on port 853. Both encrypt the query and authenticate the resolver.
TLS — Transport Layer Security
TLS encrypts the channel and authenticates the server (and optionally the client). It runs on top of TCP before HTTP or any other application protocol.
TLS 1.3 Handshake
Client Server
|--ClientHello (key_share)----->| (sends ephemeral public key)
|<-ServerHello, Certificate----| (sends cert + signed key_share)
| (verify cert chain) |
|--Finished-------------------->| (1 RTT total)
|<--------Application data------|
TLS 1.3 reduced the handshake from 2 RTTs (TLS 1.2) to 1 RTT. With 0-RTT resumption, a previously connected client can send data in the very first packet — though 0-RTT data is vulnerable to replay attacks (safe for idempotent GET, not for POST).
Certificate Chains
A certificate binds a public key to a domain name, signed by a Certificate Authority (CA). Your browser trusts a set of root CAs built into the OS. The chain:
Root CA (self-signed, in OS trust store)
└── Intermediate CA (signed by Root CA)
└── Server certificate for api.example.com (signed by Intermediate CA)
The server sends the full chain (minus the root, which the client already has). The client verifies each signature up to a trusted root.
Certificate Transparency (CT) logs require all issued certs to be published in append-only public logs. Browsers check CT logs to detect misissued certificates.
mTLS — Mutual TLS
Standard TLS only authenticates the server. mTLS requires both sides to present certificates. Used for service-to-service authentication in zero-trust networks — each microservice has a cert, and the service mesh (Istio, Linkerd) enforces that only cert-holding services can communicate.
What to Know for Interviews
- DNS TTL is not just a cache hint — it’s the minimum propagation time for changes. Reducing TTL before a migration gives you fast rollback.
- Certificate validity is max 398 days (since 2020). Short-lived certs + ACME automation (Let’s Encrypt) is the modern default.
HSTS(HTTP Strict Transport Security) tells browsers to always use HTTPS for a domain — even on the first visit if preloaded. Prevents SSL stripping attacks.