These three protocols sit at the application layer and together power essentially every web interaction. DNS turns names into addresses, HTTP carries the request/response, and TLS wraps HTTP in encryption to make HTTPS. Interviewers combine them constantly, so knowing the mechanics — record types, status codes, the TLS handshake, and how caching works — pays off.
DNS: the internet's phone book
DNS (Domain Name System) resolves a human name like www.example.com into an IP address. It is a distributed, hierarchical database queried mostly over UDP port 53 (falling back to TCP for large responses or zone transfers).
The resolution chain
A recursive resolver walks the hierarchy from the top:
1. Stub resolver asks the recursive resolver (e.g. 8.8.8.8)
2. Resolver asks a Root server -> "ask the .com TLD servers"
3. Resolver asks the .com TLD server -> "ask example.com's authoritative NS"
4. Resolver asks the authoritative NS -> "www.example.com is 93.184.216.34"
5. Resolver caches the answer (per TTL) and returns it to the stub
Here is what a real query looks like:
$ dig www.example.com A +short
93.184.216.34
Record types worth knowing
| Type | Purpose | |------|---------| | A | Name → IPv4 address | | AAAA | Name → IPv6 address | | CNAME | Alias one name to another name | | MX | Mail server for the domain | | NS | Authoritative name servers | | TXT | Arbitrary text (SPF, domain verification) | | SOA | Zone metadata (primary NS, serial, TTLs) |
Caching and TTL are the performance story: every record carries a TTL telling resolvers how long to cache it. Low TTLs let you fail over quickly (change the record and clients pick it up soon); high TTLs reduce query load but slow propagation. This is a common trade-off follow-up.
HTTP: the request/response protocol
HTTP is a stateless, text-based (in HTTP/1.1) request/response protocol. A request has a method, path, headers, and optional body:
GET /search?q=cats HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
The response has a status line, headers, and body:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1256
Cache-Control: max-age=3600
<!doctype html>...
Methods and idempotency
| Method | Safe | Idempotent | Typical use | |--------|------|-----------|-------------| | GET | Yes | Yes | Read a resource | | POST | No | No | Create / trigger action | | PUT | No | Yes | Replace a resource | | PATCH | No | No | Partial update | | DELETE | No | Yes | Remove a resource |
Idempotent means repeating the request has the same effect as doing it once — important for safe retries. GET/PUT/DELETE are idempotent; POST is not (retrying can create duplicates).
Status codes
- 2xx success — 200 OK, 201 Created, 204 No Content.
- 3xx redirection — 301 (permanent), 302/307 (temporary), 304 Not Modified (cache hit).
- 4xx client error — 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests.
- 5xx server error — 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout.
Statelessness is a core property: each request is independent, so servers scale horizontally. State (login) is carried in cookies or tokens, not in the connection.
HTTP versions
| Version | Transport | Key feature | |---------|-----------|-------------| | HTTP/1.1 | TCP | Keep-alive, one request in flight per connection (head-of-line blocking) | | HTTP/2 | TCP | Multiplexed streams, header compression (HPACK), server push | | HTTP/3 | QUIC/UDP | No TCP head-of-line blocking, faster (0-RTT) setup |
HTTPS and TLS
HTTPS is just HTTP running inside a TLS tunnel on port 443. TLS provides three guarantees:
- Confidentiality — traffic is encrypted, so eavesdroppers see ciphertext.
- Integrity — tampering is detected via authenticated encryption (AEAD).
- Authentication — the certificate proves you are talking to the real server (validated against a trusted Certificate Authority).
The TLS 1.3 handshake
Client → Server: ClientHello (supported ciphers, key share)
Server → Client: ServerHello (chosen cipher, key share),
Certificate, Finished
Client → Server: Finished
... application data (encrypted) ...
TLS 1.3 completes in one round trip (down from two in TLS 1.2) and supports 0-RTT resumption for repeat visits. The shared session key is derived via (EC)DHE ephemeral Diffie–Hellman, which gives forward secrecy: capturing the server's private key later cannot decrypt past sessions because each session used a fresh ephemeral key.
Certificate chain
Your browser trusts a set of root CAs. The server presents a leaf certificate signed by an intermediate, signed (eventually) by a trusted root. The browser verifies the chain, that the certificate is unexpired, and that the domain matches the certificate's Subject Alternative Name.
Putting it together
An HTTPS request is: DNS lookup (name → IP), TCP handshake (connection), TLS handshake (encryption + auth), then HTTP request/response inside the encrypted tunnel. Each layer builds on the one below.
In the interview
- Trace DNS resolution root → TLD → authoritative, and explain TTL caching trade-offs.
- Know status-code families and idempotency — retries depend on it.
- Explain what TLS provides (confidentiality, integrity, authentication) and the certificate chain.
- Mention TLS 1.3's 1-RTT handshake and forward secrecy for bonus depth.