How DNS Turns Website Names into IP Addresses

Why humans use names, networks use numbers

Routers forward traffic using numeric IP addresses, not domain names — the addressing scheme covered in how routers find a path across the internet depends on it. People, understandably, remember words far better than strings of numbers. The Domain Name System (DNS) exists to bridge that gap: it translates a memorable name like a website's domain into the numeric IP address that networks actually use to route traffic there.

It's easy to underestimate how central this small translation step is. Nearly every activity online — visiting a site, sending an email, opening an app that talks to a server — starts with some form of DNS lookup, even when it happens so quickly and quietly that most people never notice it's happening at all.

The DNS hierarchy

A full DNS lookup, when one is actually needed, moves through a hierarchy. Your device first checks its own local cache and your browser's cache for a recent answer. If nothing's cached, it asks a recursive resolver — often run by your ISP or a public provider — to do the lookup on its behalf. That resolver, if it doesn't already have an answer cached either, queries a root server to find out which servers handle the domain's top-level domain (like .com or .org), then queries that TLD server to find the domain's authoritative server, and finally queries that authoritative server for the actual IP address.

Each layer in this hierarchy only needs to know a narrow slice of information: a root server just needs to know which servers handle each top-level domain, not every individual website underneath it. That narrow responsibility at each layer is what lets the system scale to the enormous number of domains that exist without any single server needing to know about all of them.

Common record types and TTL

DNS stores several kinds of records for a domain. An A record maps a name to an IPv4 address; an AAAA record does the same for IPv6. A CNAME record points one name to another name rather than directly to an address, useful for aliasing. An NS record identifies which servers are authoritative for a domain. Every record also carries a TTL (time to live), which tells resolvers how long they're allowed to reuse a cached copy of that answer before checking again — a short TTL allows faster updates at the cost of more frequent lookups, while a long TTL reduces lookup traffic but slows down how quickly changes take effect everywhere.

Site owners choose TTLs deliberately based on how often they expect to change something. A domain that rarely changes its server might use a TTL measured in hours or days, since there's little downside to a slower update. A domain planning a migration will often shorten its TTL in advance, so that when the change actually happens, cached copies of the old answer expire quickly instead of lingering.

Why most lookups are much shorter than the full hierarchy

In everyday browsing, the full root-to-authoritative sequence is the exception, not the rule. Resolvers cache answers for popular domains and reuse them for many different users until the TTL expires, and your own device and browser keep short-lived caches too. The practical result is that the large majority of DNS lookups you make in a day are answered almost instantly from a cache, with the full hierarchy only coming into play for domains that genuinely haven't been looked up recently by anyone your resolver serves.

Recursive vs. iterative, briefly

Your device typically makes a recursive request: it asks the resolver for a final answer and expects one back, without handling any of the intermediate steps itself. The resolver, in turn, often works iteratively behind the scenes — asking one server, following the referral it gets to the next server, and repeating until it reaches an authoritative answer. You only ever see the simple, recursive side of that exchange.

This division of labor is convenient for everyone involved. Your device gets to ask one simple question and receive one simple answer, without needing to understand the DNS hierarchy at all, while the resolver — which is built and optimized specifically for this job, and which benefits from serving many devices' worth of cached answers at once — absorbs all of the complexity of actually working through it.

Encrypted DNS: DoH and DoT

Traditional DNS queries travel in plain text, meaning anyone on the network path could potentially observe which domains a device is looking up. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt that query, protecting it from casual observation in transit. It's worth being precise about what this does and doesn't protect: it hides the DNS query itself, but the destination IP address a connection ultimately reaches is still visible at the network level, and the destination server still knows who's connecting to it.

Many browsers and operating systems now support DoH or DoT by default, or make it easy to turn on, often paired with a choice of which resolver to trust. Switching resolvers is unrelated to changing your ISP or your internet plan — it only changes who performs the translation step, not how your traffic actually reaches its destination afterward.

Failures, stale records, and "propagation"

When someone changes a domain's DNS records — pointing it to a new server, for instance — the change doesn't appear everywhere instantly. Resolvers and devices that already cached the old answer keep using it until that record's TTL expires, which people commonly describe as "DNS propagation." It's a bit of a misnomer: nothing is actually traveling slowly across the internet. Cached copies are simply expiring on their own independent schedules.

This is also why testing a DNS change from one device right after making it can be misleading: that device may simply have an unusually short remaining cache, or none at all, while most other visitors are still seeing the previous answer until their own cached copies expire on their own timelines.

DNSSEC: authenticity, not encryption

DNSSEC adds digital signatures to DNS records, letting a resolver verify that an answer really came from the legitimate authoritative source and wasn't altered along the way. This protects against certain kinds of tampering and spoofing, but it's an authenticity check, not encryption — DNSSEC-signed queries and answers can still be observed in transit unless also combined with an encrypted transport like DoH or DoT.

What this means for your connection

A slow or unreliable DNS resolver can add noticeable delay before a connection even starts, independent of your actual download or upload speed — which is one reason switching to a faster or more reliable resolver sometimes makes browsing feel snappier without changing your internet plan at all. If a specific site seems unreachable while everything else works fine, a DNS issue — a stale cached record, a resolver problem, or a domain configuration error — is worth ruling out before assuming your connection itself is at fault.

DNS is easy to overlook precisely because it usually works invisibly and quickly. When it doesn't, the symptom — a page that simply won't load, with no obvious error — can look like almost any other kind of connection problem, which is exactly why it's worth checking early rather than last.