Core Architecture · Topic 7 of 8

DNS & TLS Certificate Chains

200 XP

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

TypePurposeExample
AIPv4 addressapi.example.com → 93.184.216.34
AAAAIPv6 addressapi.example.com → 2606:2800::1
CNAMECanonical name aliaswww → example.com
MXMail exchangeexample.com → mail.example.com
TXTArbitrary text (SPF, DKIM, verification)
NSNameserver delegationexample.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.