The half second nobody thinks about
Every time you type a domain into a browser, a small negotiation happens before a single byte of the actual website loads. Your computer does not know where toolsinpocket.com lives. It knows the name, not the address. DNS is the system that turns one into the other, and it does the job so quietly that most people never think about it until the day it breaks.
I care about this because DNS failures do not look like DNS failures. They look like a broken website, a down server, or an email problem. If you understand the lookup chain, you can tell in two minutes whether the problem is the site or the signposts pointing to it. If you do not, you will restart servers that were never the problem. I have done exactly that.
The lookup chain, step by step
When you request a domain, your browser first checks its own cache. If it recently resolved the name, it reuses the answer. If not, it asks the operating system, which keeps its own cache. Only when both come up empty does the request leave your machine and travel to a recursive resolver, usually one run by your ISP, or a public one like Google's 8.8.8.8 or Cloudflare's 1.1.1.1.
If the resolver does not have the answer cached, it walks the hierarchy. It asks a root server, which points it to the servers for the top level domain, like .com. Those servers point it to the authoritative nameservers for the specific domain. The authoritative server gives the final answer: the IP address. The resolver caches that answer, hands it back to your machine, and your browser finally connects to the address using something you can verify with an IP address lookup.
The whole chain typically takes tens of milliseconds, and thanks to caching, most lookups never travel the full path. That caching is the key to almost everything confusing about DNS, including the famous propagation myth we will get to shortly.
The record types you will actually touch
DNS holds more than IP addresses. A domain's zone is a collection of records, each with a type and a purpose. You can inspect any of them with a DNS lookup instead of guessing. In practice, four or five types cover nearly everything a site owner does.
- A records map a name to an IPv4 address. This is the classic record: yourdomain.com points to 203.0.113.10.
- AAAA records do the same job for IPv6 addresses.
- CNAME records are aliases. www.yourdomain.com can be a CNAME to yourdomain.com, so both resolve to the same place without duplicating addresses.
- MX records tell the world which servers accept email for your domain, with priority numbers so backups exist.
- TXT records hold arbitrary text, which in practice means verification strings and email authentication like SPF, DKIM, and DMARC.
- NS records name the authoritative servers for the domain, which is what actually changes when you switch DNS providers.
TTL: the setting that decides how long mistakes last
Every DNS record carries a TTL, time to live, measured in seconds. It tells every cache in the chain how long it may keep the answer before asking again. A TTL of 3600 means resolvers can serve the cached answer for up to an hour. A TTL of 86400 means a full day.
This is where I made my most expensive DNS mistake. I once migrated a client site to a new host while the records still had a 24 hour TTL, and I changed the records the same afternoon as the move. For the next day, some visitors landed on the new server and some on the old one, depending on what their resolver had cached. I spent hours convinced the migration was broken. It was not. I had simply told the entire internet it could keep the old address for a day, and the internet took me at my word.
The fix is boring and reliable: lower the TTL to something like 300 seconds at least a day before any planned change, make the change, confirm it, then raise the TTL back up. Low TTLs mean faster fixes but more lookup traffic. High TTLs mean fewer lookups but slower corrections. Pick per situation, not per superstition.
The propagation myth
People say DNS changes take 24 to 48 hours to propagate, as if the new record travels the world like a rumor. That is not how it works. There is no push, no broadcast, no wave. The authoritative server has the new answer the moment you save it. Everything else is caches expiring on their own schedules.
A resolver that cached your old record five minutes before your change will serve the stale answer until its copy of the TTL runs out. A resolver that never cached your domain will get the new answer instantly. That is why your phone on cellular data may see the new site while your laptop on office wifi sees the old one. Different resolvers, different cache states, nothing broken.
The 48 hour figure survives because registrars use it as legal cover for the worst case, mostly around nameserver changes at the TLD level, which historically updated more slowly. For an ordinary A record change with a sane TTL, most of the world sees the update within the old TTL window. Waiting two days is rarely necessary. Understanding the cache is.
Debugging DNS without guessing
When a site misbehaves after a DNS change, resist the urge to keep refreshing. Query the authoritative answer directly and compare it with what your local resolver says. If the authoritative server has the new value and your resolver has the old one, the record is fine and you are just waiting out a cache. If the authoritative server itself has the wrong value, you saved the wrong thing, and no amount of waiting will help.
Google's DNS over HTTPS JSON API, linked below, is genuinely useful here because you can query it from any browser and read the answer, including the remaining TTL, in plain JSON. Between that, a DNS lookup for the record types, and an IP address lookup to confirm where an address actually points, you can diagnose most DNS problems in minutes. I wrote more about what the address side reveals in what your IP address reveals.
What DNS cannot do
DNS answers one question: what address serves this name. It does not make your pages load faster once connected, it does not fix a misconfigured server, and it has nothing to do with how your pages appear when shared. If your link previews look wrong on social platforms, that is markup, not DNS, and a meta tag generator is the right tool for that job.
Keep the mental model simple. Names on one side, addresses on the other, caches in the middle with timers. Almost every confusing DNS behavior, from split results to slow updates, is just a timer you set earlier doing exactly what you told it to do.
Questions people ask
As long as the old record's TTL, plus a little resolver variance. If the old TTL was 3600 seconds, expect most of the world to see the new answer within about an hour. The 24 to 48 hour figure is a worst case for nameserver changes, not a normal expectation.
An A record maps a name directly to an IPv4 address. A CNAME maps a name to another name, which then resolves onward. CNAMEs are convenient aliases, but the root of a domain generally cannot be a CNAME, which is why the bare domain usually gets an A record.
They are asking different resolvers with different cache states. A resolver that cached the old record before your change serves the stale answer until its TTL expires. Nothing is broken; the caches simply have not all timed out yet.
You need the basics. Email verification, site migrations, subdomains, and TXT records for services all pass through DNS. Knowing how to read a lookup result means you can verify your host did the right thing instead of taking it on faith.