The DNS lookup flow in 5 steps
When you type lemwatch.com into a browser, the browser doesn't know the IP address. It asks a chain of servers, each of which knows part of the answer. The five steps are browser cache, recursive resolver, root server, TLD server, and authoritative name server. Each step either returns a cached answer or hands the query down the chain.
1. Browser & OS cache
Before any network traffic, the browser checks its own cache, then the operating system's. If the domain was looked up recently, the IP is returned instantly with no DNS query at all. Cache lifetime is controlled by the record's TTL (time-to-live).
2. Recursive resolver
If the local cache is cold, the OS sends the query to a recursive resolver — usually run by your ISP, or a public one like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google). The resolver's job is to chase the answer through the rest of the hierarchy on your behalf and cache the result.
3. Root name server
There are 13 root server clusters worldwide (named A through M). The resolver asks one of them where the .com servers live. The root server doesn't know the answer for lemwatch.com — it just points to the authoritative servers for the .com TLD.
4. TLD name server
The resolver then asks a .com TLD server which name server owns lemwatch.com. The TLD server returns the authoritative name server addresses (e.g. ns1.example.com).
5. Authoritative name server
Finally, the resolver asks the authoritative server for lemwatch.com's A record (IPv4) or AAAA record (IPv6). That answer is returned to the resolver, cached, and passed back to the browser. The full round-trip typically takes 20–120 milliseconds for an uncached lookup, and under 5ms for a cached one.
Why DNS caching matters
Without caching, every page load would trigger five hops through the DNS hierarchy. With caching, repeat lookups are effectively free. The TTL on each record tells resolvers how long to cache it — short TTLs (60–300 seconds) make changes propagate fast but increase load, long TTLs (3600–86400 seconds) reduce load but slow propagation.
How DNS breaks (and how to spot it)
- Stale cache — Old records persist past a domain move. Flushing the local resolver cache usually fixes it.
- NXDOMAIN responses — The authoritative server says the record doesn't exist. Common after a typo or an accidentally-deleted record.
- SERVFAIL responses — The authoritative server is unreachable or the DNSSEC signature failed. Usually a provider outage.
- Slow lookups — Resolver is overloaded or the authoritative server is geographically far. Switching to a faster public resolver often helps.
- Mismatched A/AAAA records — IPv4 resolves but IPv6 fails (or vice versa), causing intermittent failure depending on the client's network.
What to monitor
For production sites, the things that matter are: resolution latency (slow DNS is invisible until you measure it), record change detection (someone modifies an A or NS record without telling the team), and NS-record drift (a registrar update fails halfway). Lemwatch's DNS monitoring tracks all three on every site you add and alerts on any record hash change.