Question 1

You moved shop.example.com to a new IP and updated the A record. The old record had a TTL of 86400. Hours later some users still hit the old server. What is the most likely cause?

Accepted Answer

Resolvers and clients cached the old record and will keep it until the 86400 second TTL expires Recursive resolvers, OS stubs and browsers may cache an answer for up to its TTL, so a one day TTL means up to a day of stale answers. Lower the TTL well before a migration. Propagation is not a push process between authoritative servers, it is cache expiry. Browsers do honor TTLs (often capping them shorter). PTR records are for reverse lookups and play no part in forward resolution.

Question 2

A client in Sydney makes its first HTTPS request (HTTP/1.1 over TCP, TLS 1.3, DNS already cached) to a server with 150 ms RTT. Roughly how long until the first response byte arrives, ignoring server time?

Accepted Answer

450 ms TCP handshake costs 1 RTT, the TLS 1.3 handshake 1 RTT, then the request and response 1 RTT: 3 x 150 = 450 ms. 150 ms ignores both handshakes. 300 ms forgets one of them (often candidates assume TLS is free). 600 ms is the TLS 1.2 number, which needed 2 RTTs for the full handshake.

Question 3

A page loads 20 small API calls to the same origin over HTTPS. After the first call, the rest are noticeably faster even though the server time is unchanged. What explains this best?

Accepted Answer

The browser reused the already established TCP and TLS connection, skipping the handshakes Persistent connections (keep-alive in HTTP/1.1, multiplexing in HTTP/2) let later requests skip DNS, TCP and TLS setup, saving 1 to 2 RTTs each. Server time was stated unchanged, so JIT is ruled out. DNS answer size does not change. Slow start applies per connection; a new connection starts small again, so it argues for reuse rather than explaining new connections being faster.

Question 4

Users in Europe load a static JS bundle from an origin in us-east. You put a CDN in front with a long Cache-Control max-age. Why does p50 load time drop most for repeat requests from Europe?

Accepted Answer

The edge serves the cached file from a nearby POP, so handshakes and transfer cross a much shorter RTT Latency is dominated by round trips times distance. A cache hit at a nearby POP turns a transatlantic RTT of around 80 to 100 ms into a few ms for every handshake and data round trip. Compression may help but is not the main effect and origins can compress too. CDNs mostly serve HTTP over TCP and TLS; even with HTTP/3 there is still a handshake. Certificate validation is never skipped.

Question 5

A user types shop.example.com (no scheme). The site sends Strict-Transport-Security on HTTPS responses and is not on the browser preload list. On the very first visit, which statement is true?

Accepted Answer

The first request can go out over plain HTTP and is then redirected; HSTS only protects later visits HSTS is trust on first use: the browser learns the policy from an HTTPS response, so the first plain HTTP request is exposed to downgrade attacks. Preloading closes that gap. The header is an HTTP response header, not DNS. Many browsers now try HTTPS first, but HSTS still matters because it forbids falling back and blocks click-through on certificate errors. HSTS has nothing to do with DNS encryption.

Question 6

You create api2.example.com. A teammate queried it five minutes before you created it and got NXDOMAIN. They still get NXDOMAIN now while you resolve it fine. What governs how long their resolver keeps the NXDOMAIN?

Accepted Answer

Negative caching, bounded by the zone SOA record (minimum field and SOA TTL) RFC 2308 lets resolvers cache NXDOMAIN for the lesser of the SOA TTL and the SOA minimum field. Their resolver has not asked again. The new A record TTL is irrelevant because their resolver never fetched that record. Saying NXDOMAIN is never cached is the common misconception that causes this confusion. HSTS concerns HTTPS policy, not DNS.

Question 7

A multiplayer game sends player positions 30 times a second. Why do many games use UDP (or QUIC datagrams) instead of TCP for this?

Accepted Answer

TCP head of line blocking would hold new positions behind a lost old one; with UDP the game drops stale updates and uses the latest TCP delivers bytes in order, so one lost segment stalls everything after it until retransmission, and a retransmitted old position is useless. UDP lets the app skip it. UDP packets do not travel faster on the wire; the 'faster' claim is the common wrong answer. UDP has no encryption. TCP can send small segments fine.

Question 8

HTTP/2 multiplexes many streams over one TCP connection. On a lossy mobile network, one lost packet stalls all streams. What does HTTP/3 over QUIC change?

Accepted Answer

Streams are independent at the transport layer, so a loss stalls only the affected stream, and connection setup combines transport and TLS QUIC runs over UDP and does its own per stream reliable delivery, removing TCP level head of line blocking, and integrates TLS 1.3 into its 1 RTT handshake. QUIC is always encrypted. HTTP/3 uses one QUIC connection, not many TCP connections. QUIC has congestion control like TCP.

URL to page, TCP vs UDP and QUIC interview questions

URL to page: DNS, handshakes, caching

TCP vs UDP and QUIC

More networking topics

Practise these on your commute