Every time I type a website name into a browser and a page loads, a lookup happened first that I never saw. The name I typed — something readable, meant for a person — had to be turned into a number the network can actually route to. That turning is the job of DNS, the Domain Name System. I work with it every time I move a site or set up email, and most mysterious website problems turn out to be DNS doing exactly what it was told. Here is how it works, in plain words.
Names Are for People, Numbers Are for Machines
Computers reach each other using IP addresses — numerical addresses that identify a particular server on the network, either as numbers separated by dots or, in the newer and longer form, as numbers and letters separated by colons. Either way, nobody wants to memorize one for every site they visit.
So we use names instead. DNS is the directory that connects the two: give it a name, and it answers with the address. It is often compared to a phone book, with one difference — there is no single book. The directory is spread across millions of servers, each responsible for its own small piece.
Step One: Check What Is Already Known
When I ask for a site, my computer does not start by searching the whole internet. It checks memory first. My browser keeps a short-term cache of names it has looked up recently, and the operating system keeps one too. If the answer is already there and has not expired, that is the end of the lookup.
If nothing is cached locally, the question goes to a recursive resolver — usually a server run by my internet provider, or a public resolver I have chosen on purpose. The resolver’s job is to track down the answer on my behalf and hand it back.
Step Two: Asking Down the Chain
A domain name reads in layers, from the most specific part on the left to the most general on the right. The resolver follows those layers from the top down, asking servers that each know one level.
First, it asks a root server who handles the ending — the top-level domain, such as .com or .dev. The root does not know my site’s address, only who handles that ending.
Next, it asks one of those servers which servers are authoritative for that exact domain — again, just a referral one level closer.
Finally, it asks the authoritative nameserver, which holds the domain’s actual records and is usually run by the registrar or hosting company. That server gives the real answer. The resolver returns it, my browser connects, and only then does the page load. Nobody holds the whole directory, and nobody needs to.
The Records Themselves
An authoritative nameserver does not hold one answer per domain. It holds a set of records, each answering a different kind of question.
An A record points a name to an IPv4 address, and an AAAA record points it to an IPv6 address. These are the records a browser needs.
A CNAME record points one name at another name instead of at an address — useful when a subdomain should follow wherever the main name goes.
An MX record says where email for the domain should be delivered — a separate answer from the website’s address, which is why a site can be hosted in one place and its email handled somewhere else entirely.
A TXT record holds plain text attached to the domain, commonly used to prove ownership to a service, or to publish rules helping other mail servers judge whether email claiming to come from that domain is legitimate.
Why Changes Take Time: TTL
Every record carries a TTL — a time to live — telling resolvers how long they may cache that answer before asking again. When I move a website to a new host and update its A record, the change takes effect at the authoritative server immediately. But every resolver and computer that cached the old answer keeps using it until its copy expires.
That delay is usually described as the change “propagating,” but nothing is traveling. Old copies are simply aging out, on their own clocks. It is also why a site can load from the new host on my phone and the old host on my laptop at the same moment — their caches expire at different times. The fix is usually not another change; it is waiting for caches I cannot see to let go.
The Practical Part
Here is my takeaway. When a website or an inbox breaks after a move, I check DNS before anything else, because DNS is where a correct server gets sent no visitors, and where email quietly goes to the wrong place while the website looks fine. The website record and the email record are separate answers; fixing one says nothing about the other. And when a move is coming, I lower the TTL ahead of time, so the old answer expires quickly on moving day.
DNS is invisible when it works. But it is the first system every visit and every email passes through — and once I understood it is just a chain of referrals ending at one server that actually knows, it stopped being magic and started being a checklist.