DNS & TLS/HTTPS

Concept#

DNS, Domain Name System#

DNS is a distributed, hierarchical key-value store that maps hostnames to IP addresses (and other record types). It's often called the "phonebook of the internet", but that analogy understates how complex and impactful it is.

The DNS hierarchy

Root nameservers (13 sets, operated by IANA)
         ↓
TLD nameservers (.com, .org, .io, operated by registries)
         ↓
Authoritative nameservers (your zone, operated by you/your DNS provider)
         ↓
Records (A, AAAA, CNAME, MX, TXT, NS, etc.)

The full resolution process

1. Browser DNS cache (fastest, memory, ~0ms)
2. OS resolver cache (checks /etc/hosts on Linux/Mac, registry on Windows)
3. Recursive resolver (your ISP's or a public one like 1.1.1.1, 8.8.8.8)
   - Checks its own cache
   - If miss: queries root → TLD → authoritative nameservers
4. Authoritative nameserver returns the record
5. Recursive resolver caches the answer for TTL seconds

A full cold recursive resolution takes 50, 200ms. Subsequent lookups return the cached answer in microseconds.

DNS record types

A        hostname → IPv4 address          example.com → 93.184.216.34
AAAA     hostname → IPv6 address
CNAME    hostname → another hostname      www → example.com (cannot be on root domain)
MX       mail servers for the domain      handled by mail providers
TXT      arbitrary text                   SPF, DKIM, domain verification, ACME challenges
NS       authoritative nameservers        which servers hold the zone
SOA      zone metadata                    serial number, refresh intervals
SRV      service discovery
CAA      Certificate Authority Authorization  which CAs can issue certs for the domain

TTL (Time to Live)

TTL is the number of seconds recursive resolvers should cache a DNS record. Lower TTL = faster propagation of changes but more DNS queries. Higher TTL = more caching, faster resolution, but slower failover.

Typical values:

• Production A/AAAA records: 300, 3600s (5 min, 1 hr)
• During a planned migration: lower TTL to 60, 120s a day beforehand
• CDN CNAME records: 60, 600s (CDNs rotate IPs for load balancing)

Performance: reducing DNS lookup time

• dns-prefetch: <link rel="dns-prefetch" href="https://fonts.googleapis.com">, resolves DNS for a third-party origin early, before the resource is needed
• preconnect: goes further, resolves DNS + TCP + TLS. Use for origins you're certain will be needed
• Avoid too many origins, each new origin requires a fresh lookup

TLS, Transport Layer Security#

TLS is the cryptographic protocol that provides:

1. Confidentiality, data is encrypted, eavesdroppers see ciphertext
2. Integrity, data cannot be tampered with undetected (MAC/AEAD)
3. Authentication, the server proves its identity via a certificate signed by a trusted CA

"HTTPS" = HTTP over TLS. "SSL" is the predecessor to TLS, the term is still used colloquially, but TLS 1.0, 1.3 are the actual protocols. SSL 2.0 and 3.0 are deprecated and broken.

TLS certificate chain of trust

Root CA (self-signed, pre-installed in OS/browser trust stores)
    ↓ signs
Intermediate CA
    ↓ signs
End-entity certificate (your domain's certificate)

When a browser connects, it verifies:

1. The certificate is for the domain you're connecting to (Subject/SAN match)
2. The certificate is signed by a CA in the trust store (chain of trust)
3. The certificate hasn't expired
4. The certificate hasn't been revoked (OCSP/CRL)

Certificate types

• DV (Domain Validated), fastest, cheapest (Let's Encrypt). Only proves you control the domain. Used for most websites.
• OV (Organization Validated), verifies legal entity. Shown in certificate details.
• EV (Extended Validation), rigorous org verification. Green bar browsers used to show (deprecated in Chrome 2019).
• Wildcard, *.example.com, covers all subdomains (one level deep). Cannot cover example.com itself or a.b.example.com.
• SAN (Subject Alternative Names), one cert covers multiple domains. Modern standard; used by Let's Encrypt.

TLS 1.3 handshake (current standard)

Client → Server:  ClientHello
                  - Supported TLS version (1.3)
                  - Cipher suites (e.g., TLS_AES_256_GCM_SHA384)
                  - Key share (public key for Diffie-Hellman)
 
Server → Client:  ServerHello (chosen cipher + key share)
                  Certificate (signed by CA)
                  CertificateVerify (proves private key ownership)
                  Finished (HMAC of entire handshake)
 
Client → Server:  Finished
 
[Encrypted connection established, total: 1 RTT]

TLS 1.2 required 2 RTTs. TLS 1.3 achieves 1 RTT by sending the key share in the first message (using pre-negotiated groups).

0-RTT session resumption

For returning clients, TLS 1.3 supports 0-RTT (Early Data). The client sends data with the very first packet using a pre-shared key (PSK) from a previous session. This eliminates the handshake entirely, but with a trade-off: 0-RTT data is vulnerable to replay attacks because it's sent before the server can issue a challenge. Safe for idempotent requests (GET), dangerous for non-idempotent (POST).

HSTS (HTTP Strict Transport Security)

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

This header tells browsers to always use HTTPS for this domain for max-age seconds, even if the user types http://. After the first HTTPS visit, the browser refuses to downgrade. The preload flag adds the domain to a hardcoded browser list, protection before the first visit.

Common Mistakes#

1. Low TTL left permanently low after a migration#

Engineers lower TTL before a migration then forget to raise it. A TTL of 60s means 1 DNS query per minute per resolver, high DNS load for popular sites.

2. Using CNAME on the root domain#

CNAME example.com → myapp.vercel.app violates DNS specs (RFC 1034), a CNAME record can't coexist with other records, and the root needs SOA/NS records. Use an ALIAS or ANAME record (proprietary extension, most DNS providers support it) or an A record.

3. Certificate expiry in production#

Let's Encrypt certs expire every 90 days. Without auto-renewal (certbot, AWS ACM auto-renew), you get an outage. Set up monitoring on cert expiry (openssl s_client -connect example.com:443 | openssl x509 -noout -dates).

4. Not pinning to TLS 1.2+#

Allowing TLS 1.0/1.1 exposes you to POODLE, BEAST, and other attacks. Most CDNs/load balancers default to TLS 1.2+ now, but custom server configs sometimes still allow old versions.

5. Mixing HTTP and HTTPS resources (mixed content)#

Browsers block active mixed content (scripts, iframes over HTTP on an HTTPS page) and warn on passive mixed content (images). One HTTP resource can silently expose data or enable injection. Always serve all resources over HTTPS.

Best Practices#

• Use Let's Encrypt + auto-renewal for all domains. Free, automated, and trusted.
• Enable HSTS with includeSubDomains. Submit to the preload list for your production domain.
• Set DNS TTL to 3600 in steady state; lower to 300 before any planned migration.
• Use a CAA record (0 issue "letsencrypt.org") to restrict which CAs can issue certificates for your domain, prevents misissued certs.
• Monitor cert expiry, set a Datadog/PagerDuty alert 30 days before expiry.
• Prefer ECDSA certs over RSA, smaller and faster to verify.

Performance Tips#

• DNS lookup time is real but often cached. The first visit to a new origin pays; subsequent visits don't. This is why reducing origin count matters most for first visits.
• OCSP stapling eliminates the browser's OCSP request (checking if a cert is revoked) by having the server attach the OCSP response directly. Without stapling, the browser makes an extra network request to the CA. Enable on your web server.
• TLS session tickets let the server resume sessions without re-running key exchange. Store ticket keys securely and rotate them, leaked keys allow decrypting past sessions.
• Certificate pinning (pinning expected cert public keys) protects against CA compromise, but causes outages when certs rotate. Recommended only for native apps with controlled update cycles, not websites.