Few things feel as unfair as changing a DNS record, hitting refresh, and getting the same old site back. The record is live. Your colleague can see it. Your client can see it. You cannot. Nothing is broken. A cache somewhere between your keyboard and the authoritative server is holding an older answer, and nobody ever explained the timings to you.
DNS is the part of the stack most developers learn by accident, usually late at night on a launch. Here is the whole journey from browser to authoritative nameserver, followed by the commands and habits that make debugging it far less mysterious.
The cast of characters
A single lookup can involve five or six parties, and every one of them is allowed to remember the answer for a while. Knowing who is who makes the rest much easier to reason about.
- The browser. It keeps a small DNS cache of its own. If secure DNS (DNS-over-HTTPS) is switched on, the browser may bypass your operating system's resolver entirely and ask its own provider instead.
- The operating system's stub resolver. A thin client that reads your hosts file and forwards queries to whichever DNS server your network settings point at.
- The recursive resolver. Your ISP's server, your router, or a public service such as 1.1.1.1 or 8.8.8.8. This is the workhorse that walks the hierarchy and caches what it finds.
- The root and TLD servers. These usually do not know your answer. They know who to ask next.
- Authoritative nameservers. The source of truth for the zone. Wherever your DNS is hosted, this is where the record you edited actually lives.
What happens during a lookup
Say someone types example.co.uk into a browser. If nothing is cached anywhere, the conversation goes roughly like this.
- The browser checks its own cache, then hands the query to the operating system's stub resolver.
- The stub resolver checks the hosts file and its local cache, then sends a recursive query to the configured resolver.
- If the recursive resolver already holds an answer that has not expired, it returns it immediately. The lookup ends here, in milliseconds.
- If not, the resolver asks a root server. The root does not know the address, so it replies with the nameservers for the relevant top-level domain.
- The resolver asks that TLD server, which returns the authoritative nameservers delegated for your domain.
- The resolver asks an authoritative nameserver, receives the A record and its TTL, caches it, and passes it back down the chain. The browser connects to that IP address.
The full cold lookup is a handful of network round trips, so it costs tens of milliseconds rather than seconds. Almost every lookup after that is served from a cache.
The records you will actually touch
You do not need to memorise the whole specification. These are the types that cover the vast majority of day-to-day work.
- A — maps a name to an IPv4 address. Multiple A records on the same name give you crude round-robin balancing.
- AAAA — the same thing for IPv6. If your host has no IPv6 address, do not add one just to look modern.
- CNAME — an alias pointing one name at another. It cannot sit alongside other records on the same name, and a bare domain (the zone apex) usually cannot be a CNAME, though some providers offer "flattening" to fake it.
- MX — mail routing. These point at hostnames, never at raw IP addresses, and they carry a priority number.
- TXT — free text, used for domain verification, SPF and DKIM. One name can hold several TXT records, so check for existing ones before adding another.
- NS — the nameservers delegated for the zone. A mismatch between the NS records at your registrar and those at your DNS provider is one of the most common causes of a domain that "does not work".
- SOA — zone metadata, including a serial number and the timers that govern negative caching.
TTLs, caching and so-called propagation
Every record carries a TTL: a time to live, in seconds, telling resolvers how long they may keep the answer. A TTL of 300 means a resolver can serve that answer for five minutes without checking again. A TTL of 86400 means a full day.
This is why "DNS propagation" is a misleading phrase. Nothing is spreading outward across the internet. Resolvers are simply holding old answers until their timers run out, and different resolvers started their timers at different moments. That is the entire reason two people can see two different versions of your site at the same time.
Two practical consequences follow. First, lower the TTL on the records you plan to change at least one old-TTL period beforehand, so the switch is quick when it matters. Second, failed lookups are cached too, governed by the SOA record. A typo that briefly pointed a domain at nothing can linger, which is why the first thing to check when a site will not come back is whether the record is correct now, not whether it was correct five minutes ago.
Debugging DNS in practice
Start with dig
dig example.co.uk A +short gives you the bare answer. Drop +short and you get the useful detail: which server replied, the status code, the TTLs, and the answer section. The TTL shown is a countdown, so running the same query twice and watching it fall tells you exactly how much cache is left.
Follow the delegation
dig +trace example.co.uk walks the hierarchy from the root down, showing who delegates to whom. If the trace stops early, the problem is upstream of your DNS provider. dig NS example.co.uk shows the nameservers currently delegated; compare that list with the ones shown in your provider's dashboard. When those two disagree, nothing else you change will take effect.
Query a specific resolver
Your laptop's cache will lie to you. Query public resolvers directly instead: dig @1.1.1.1 example.co.uk and dig @8.8.8.8 example.co.uk. To see the truth with no caching in the way, ask the authoritative server itself: dig @ns1.yourprovider.net example.co.uk. If that returns the new value, your change is live and the rest is patience.
Check the layers above
Once DNS resolves correctly, stop blaming it. curl -v https://example.co.uk shows the IP it connected to and the certificate it received, which quickly separates a DNS problem from a TLS or virtual host problem. Remember too that if your site sits behind a proxy or CDN, the public A records belong to that service, not to your origin server. Changing origin DNS records will have no visible effect at all.
A short routine for your next DNS change
- Lower the TTL on the affected records a day in advance.
- Make one change at a time and verify it against the authoritative nameserver.
- Confirm the answer from two public resolvers.
- Wait out the old TTL before deciding anything is wrong.
- Raise the TTL back to something sensible once you are happy.
Write the TTL you chose next to the change in your ticket, along with the time you made it. The next person to debug this will know precisely how long to wait before panicking, and that person may well be you.
Photo: Brett Sayles / Pexels
