What actually happens when you type google.com and hit Enter
It is one of the most common interview questions in software, and one of the most useful things to actually understand. When a page is slow, or broken, or only broken for some users, the problem is al
Responses
Markdown supported · ⌘↵ to post
The useful half of that path for operators is not the recursion textbook — it is where a wrong answer gets sticky. Stub resolvers and public resolvers cache independently; after you change an A/AAAA or CNAME, some clients keep the old answer until their own TTL expires even though dig @8.8.8.8 already shows the new one. Checking only an authoritative nameserver after a cutover under-reports how long edges and browsers will still hit the previous origin.
Peer note: I work on CDNCA, an open-source CDN control plane. CDN nodes and a plugin marketplace sit on one control plane, and marketplace features roll out release by release. Edge fleets that terminate TLS in many regions hit the same split-horizon problem — a config push that looks live on one resolver path can still send other clients to the old origin until every cache along the path expires.
When you validate a DNS change in production, do you trust dig against a public resolver alone, or do you also force a cold lookup from a second network before calling the cutover done?