When I type a domain name into a browser, I am not really telling the browser where anything lives. I am giving it a name that people can remember. Computers on the internet reach each other using IP addresses — numbers that identify a particular machine or service. DNS, the Domain Name System, is the system that translates the name I remember into the number the network actually needs. Without it, I would have to keep lists of numbers for every site and service I use, and change those lists every time a server moved.
Start With the Parts of a Name
A domain name is read in pieces, from right to left. The rightmost part, like .com, is the top-level domain. To its left is the registered domain — the name someone actually bought from a registrar. To the left of that can be subdomains, like www or mail, which the owner of the domain can create for different services. Each level narrows the question: which top-level domain, which registered domain under it, and which host or service under that domain?
That structure matters because DNS is not one big list held in one place. It is delegated. Different organizations are responsible for different levels, and each level points to the next one down. That is why a domain owner can move a website to a new server, change email providers, or point a subdomain somewhere else without asking the whole internet for permission — they control the records for their own zone.
What Happens When You Visit a Site
When my browser needs an address it does not already have cached, it asks a resolver — usually a service run by my internet provider, my router, or a public resolver I have chosen. The resolver does the walking for me.
First, if the answer is not cached, the resolver asks a root nameserver where to find the nameservers for that top-level domain, such as .com. Next it asks one of those top-level nameservers where to find the authoritative nameservers for the specific domain. Then it asks the domain’s own authoritative nameserver for the actual record — for a website, usually an A record for an IPv4 address or an AAAA record for an IPv6 address. The resolver returns that address to my browser, and only then does the browser connect to the server and start the separate process of loading the page, including the encryption setup for HTTPS.
Most of the time I never see any of this, because caching makes it fast. Resolvers and browsers remember answers for a period set by the record itself, called its TTL, or time to live. A long TTL means fewer lookups and less load, but slower changes. A short TTL means a move or fix takes effect sooner, at the cost of more frequent queries. When I am planning a server change, I lower the TTL in advance, make the change, and raise it again once the new answer is stable.
Records Are Not Just for Websites
The A and AAAA records are only part of the picture. MX records tell other mail servers where to deliver email for a domain. TXT records carry plain text that other systems check — commonly to prove domain ownership or to publish email authentication information that helps receivers judge whether mail claiming to be from a domain is legitimate. CNAME records make one name an alias of another, so a subdomain can follow a service’s own hostname instead of a fixed address. NS records name the authoritative nameservers themselves — the delegation at the heart of the whole system.
Where DNS Goes Wrong
In my experience, most DNS trouble comes from a short list of ordinary causes. A record was edited but the old answer is still cached until its TTL expires, so some visitors see the new server and some still see the old one. A name was pointed at the wrong address, or a needed record — especially for email — was deleted during a cleanup. Or the delegation itself is wrong: the registrar points to one set of nameservers while the records were edited on another, so the changes exist but nobody is being sent to them.
Why This System Has Lasted
What I appreciate about DNS is that it solves a human problem and a technical problem at the same time, and it does it by delegation instead of central control. I get names I can say out loud, remember, and print. Server owners get the freedom to move machines, change providers, and split services across different companies without changing the public name. The network gets a system that scales because no single server has to know everything.
Next time a site will not load, or mail stops arriving after a change, it is worth asking the DNS question before blaming the server: what name was queried, what record was returned, who is authoritative for it, and how long ago could that answer have been cached? More often than I expected when I started running servers, the server was fine. The directions to it were the problem.