How cloud DNS resolves a URL to an IP
end-to-end DNS resolution flow.
recursive resolver queries root, then TLD, then your authoritative cloud DNS zone; the matching record returns an IP, cached per TTL.
skipping the recursive resolver or caching.
What's really being asked
The question checks that you grasp the layered, hierarchical nature of DNS and can place a managed cloud DNS service correctly as the authoritative source for your domain.
The full answer
First the browser and operating system check their own caches. On a miss, the request goes to a recursive resolver, often run by the ISP or a public provider like 8.8.8.8. The resolver, if it has nothing cached, queries a root nameserver, which returns the address of the top level domain servers for the extension such as .com. The TLD server returns the authoritative nameservers for your domain, which are your cloud DNS zone, for example Route 53 or Azure DNS. The resolver queries that zone, which returns the A record for IPv4 or AAAA for IPv6. The resolver hands the IP back to the browser, which opens a TCP connection. Every step caches the answer for the duration of the record's TTL, so subsequent lookups are far faster and may never reach the authoritative tier.
The mistakes people make
Describing resolution as a single direct call to your server skips the resolver and root and TLD hierarchy. Forgetting caching and TTL misses why DNS scales and why propagation delays exist. Confusing authoritative and recursive roles is a frequent slip.
What usually comes next
What is the difference between an A record and a CNAME? How does a low TTL affect failover and load? What is an alias record in Route 53?
A concrete example
A user opens app.example.com. The resolver learns from .com servers that Route 53 is authoritative, queries the hosted zone, and gets an alias record pointing at a load balancer's IP, all cached for sixty seconds so a regional failover takes effect quickly.
Interview question
Why might a freshly changed DNS record not take effect immediately for all users worldwide?
- a.Cloud DNS services only update once per day in a batch
- b.Cached answers persist in resolvers until the previous record's TTL expiresCorrect
- c.Browsers never cache DNS and always re-query the authoritative zone
- d.The root nameservers must manually approve every record change
Why? this is the answer
Resolvers cache records for the TTL set before the change, so old answers linger until that timer expires. Root servers do not approve individual records, and browsers do cache DNS.
Just read this? Test yourself on what you have been reading.
Read the original → docs.cloud.google.com
- #dns
- #networking
- #route53
- #cloud
- #resolution
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles