Every time you type a website name and press Enter, your browser faces a problem it cannot solve on its own. It knows the name, but the internet only routes traffic to numbers. Something has to translate that name into an address, and it has to do it in milliseconds, billions of times a day, without ever getting confused. That something is the Domain Name System, or DNS, and it is the quiet infrastructure underneath almost everything you do online.
Key Takeaways
DNS translates human readable domain names into IP addresses, the numbers computers use to find each other.
A lookup usually passes through four layers: your device's cache, a recursive resolver, a root server, a TLD server, and an authoritative server, though caching often skips most of them.
There are 13 named root server identities, labelled A through M, each replicated at many locations worldwide so queries reach a nearby copy.
DNS records do more than point websites at servers. They route email, verify domain ownership, and control which servers may send mail for a domain.
Classic DNS queries are unencrypted. DNSSEC checks that answers are authentic, while DNS over HTTPS and DNS over TLS encrypt the query on its way to the resolver.
What DNS Actually Does
Computers locate each other with IP addresses, such as 93.184.216.34 for example.com. Humans remember names, not strings of numbers, and names can stay stable while the server behind them moves. DNS is the distributed database that maps one to the other. It is hierarchical, like a tree, and no single server holds the whole thing. Each layer knows only enough to point the query one step closer to the answer.
That design is what lets DNS scale. Your device asks a nearby resolver, the resolver asks a small number of servers, and each of those servers answers from its own slice of the tree. The system was designed in the early 1980s, when a single shared text file of host names was already collapsing under the growth of the network, and it still runs the same basic lookup logic today.
A Lookup, Step by Step
Here is what happens when you visit a site for the first time, with nothing cached:
Your device checks its own cache. Your browser, then your operating system, looks for a recent answer. If either has one that has not expired, the lookup stops here.
A recursive resolver takes over. Your device sends the query to a recursive resolver, usually run by your internet provider, or a public one such as Cloudflare (1.1.1.1) or Google (8.8.8.8). The resolver does the legwork on your behalf.
The root server points the way. The resolver asks one of the 13 root server identities which servers handle the requested top-level domain, such as .com. The root server does not know the site's address. It only knows who to ask next.
The TLD server narrows it down. The top-level domain server for .com knows which authoritative name servers handle that specific domain, and it hands those over.
The authoritative server gives the answer. This is the only layer that holds the domain's actual records. It returns the A record, the IPv4 address, or the AAAA record for IPv6, and the resolver passes it back to your device.
Everything caches the result. Each layer stores the answer for a set time, called the TTL (Time To Live), so the next visit skips most of the chain.
On a cold lookup, that chain is a handful of network round trips. On a repeat visit, it is usually zero, because the answer is already sitting in a cache somewhere between you and the resolver. That is why the first visit to a new site sometimes feels slightly slower, and every visit after feels instant.
The Records That Run a Domain
A domain's zone file holds more than one kind of record. The most common ones:
Record | What it does |
|---|---|
A | Points a name at an IPv4 address |
AAAA | Points a name at an IPv6 address |
CNAME | Makes one name an alias of another name |
MX | Says which servers receive email for the domain |
NS | Says which servers are authoritative for the domain |
TXT | Carries text, used for ownership checks and email policies such as SPF, DKIM, and DMARC |
CAA | Limits which certificate authorities may issue certificates for the domain |
SOA | Holds administrative details about the zone itself |
A website needs an A or AAAA record. A working email setup needs MX records plus TXT records that prove the sending server is legitimate. A single typo in any of them can take a site or a mailbox offline, which is why DNS changes are usually made carefully, and with a short TTL during a migration so mistakes can be undone quickly.
A Short History: From One Text File to a Global Tree
Before DNS, the early ARPANET kept a single host table, HOSTS.TXT, maintained by hand. As the network grew in the early 1980s, that file became too slow and too fragile to keep updating by phone during business hours. In 1983, Paul Mockapetris, working at the University of Southern California's Information Sciences Institute, designed the Domain Name System to replace it with a distributed, hierarchical service.
The core of the new system was first described in RFC 882 and RFC 883 in 1983, and the design was refined into the standards every implementation still builds on: RFC 1034 (Domain Names, Concepts and Facilities) and RFC 1035 (Domain Names, Implementation and Specification), both published in November 1987. The BIND history from the Internet Systems Consortium records that sequence, from the 1983 drafts through the 1987 standards, and notes that the first working name server, called Jeeves, was written by Mockapetris in 1983 and 1984. Berkeley students soon wrote BIND, the Unix name server that carried DNS into wide use.
Why DNS Is Fast, and When It Is Not
DNS feels instant because of two tricks. The first is caching at every layer, as described above. The second is anycast: the 13 root identities are not 13 machines, but 13 addresses announced from many locations worldwide, so your query is routed to a nearby copy instead of travelling across the planet.
When DNS is slow, the cause is usually one of three things. A TTL set too long means a change takes hours to propagate to cached resolvers. A misconfigured record points visitors at the wrong server, or nowhere at all. Or the resolver itself is slow or far away, which is why switching from an ISP default to a public resolver such as 1.1.1.1 or 8.8.8.8 sometimes makes browsing feel noticeably faster. If a site loads for everyone except you, flushing your local DNS cache or trying another resolver is a reasonable first check, before assuming the site itself is down.
Security: DNSSEC, DoH, and DoT
Classic DNS has an awkward property: queries travel in plain text, and answers are trusted largely because they arrived from the expected server. Two different fixes address two different halves of that problem.
DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records, so a resolver can verify that an answer really came from the domain's authoritative server and was not tampered with on the way. It protects the integrity of the answer, but it does not encrypt the query. Anyone watching the network can still see which domains you look up.
DNS over TLS (DoT) and DNS over HTTPS (DoH) encrypt the query itself. DoT wraps queries in TLS on its own port, 853, and is commonly configured at the operating system or router level. DoH sends queries as ordinary HTTPS traffic on port 443, so it blends in with normal web traffic and is often enabled inside a single browser. Cloudflare notes the trade-off: DoT is easier for network administrators to monitor and control, while DoH gives the user more privacy from observers on the local network. Both still leave one fact unchanged: the resolver itself sees every domain you ask for. Encrypted DNS hides your queries from people watching the wire, not from the resolver you chose.
DNS in Everyday Life
You meet DNS more often than you realise. When a company moves its website to a new host, it changes an A record. When it sets up email on a new provider, it changes MX records. When it proves it owns a domain to a service like Google Search Console, it adds a TXT record. When a developer adds a subdomain for a staging site, that is a DNS record too.
And the same lookup sits behind everything else in the stack. Once DNS returns an address, the browser opens a connection and the web's other protocols take over. REST API Explained: How the Web's Most Common API Style Actually Works covers what happens after that connection is made. DNS is the step before all of it, the one that turns a name you typed into a place a computer can reach.
Frequently Asked Questions
Is DNS the same as my IP address?
No. Your IP address is where your traffic comes from. DNS is the system that translates a name into the address of the server you want to reach. They describe different ends of the same connection.
Why does a DNS change take time to work everywhere?
Because resolvers cache old answers until their TTL expires. Lowering the TTL before a planned change makes the switch faster, but a change made with a long TTL already cached can take hours to reach everyone.
Should I change my DNS resolver?
It is a reasonable experiment if browsing feels slow or if you want encrypted queries. Public resolvers such as Cloudflare's 1.1.1.1 and Google's 8.8.8.8 are easy to configure on most devices and routers, and both support DoH and DoT. Just remember that the resolver you pick can see every domain you look up, so choose one whose privacy policy you trust.
What happens if DNS goes down?
If the authoritative servers for a domain fail, nobody can resolve that domain, even though the website's server may be running perfectly. That is why DNS outages feel so total: the site is not broken, it is unreachable, because no visitor can find its address.