From Hostname to IP: What Really Happens When You Resolve a Domain

Before your service can open a connection to api.example.com, something must turn that name into an IP address, and that something is DNS, the Domain Name System. It is one of the internet's oldest and most quietly critical pieces of infrastructure, a globally distributed database that maps names to addresses and much more. Most of the time it feels instantaneous, but a single lookup can involve several servers across the world, multiple layers of caching, and rules about how long answers stay valid. When DNS misbehaves it produces some of the most confusing outages in backend work, because the symptom looks like a connection failure while the real cause is name resolution. Understanding the actual resolution path, the role of caching, and how time-to-live governs propagation turns those mysteries into diagnosable, fixable problems.

Names Versus Addresses

Computers route traffic using IP addresses, numeric labels like a string of digits that are hard for people to remember and that can change when infrastructure moves. Humans want stable, memorable names. DNS bridges this gap by mapping names to addresses, but it is more than a phone book. It supports many record types: an A record maps a name to an IPv4 address, an AAAA record to an IPv6 address, a CNAME aliases one name to another, an MX record directs email, and a TXT record holds arbitrary text often used for verification and policy. The indirection DNS provides is itself valuable: because clients look up the name fresh, operators can change the underlying address, move to a new server, or balance load across many addresses without clients needing to know or update anything. The name is the stable contract; the address is an implementation detail.

The Resolver Chain

When your application asks for a name, it does not query the authoritative source directly. It asks a recursive resolver, typically run by your operating system, your network provider, or a public service. The recursive resolver does the heavy lifting on your behalf, walking the hierarchy and returning a final answer. Your local machine often has a stub resolver that simply forwards the request to this recursive resolver. This separation matters because the recursive resolver caches aggressively, so most queries never travel far. The first lookup of a name might trigger the full multi-step journey across the world, but subsequent lookups for the same name, from you or anyone else using the same resolver, are answered instantly from cache. Understanding that a recursive resolver sits between your code and the authoritative servers is the key to reasoning about both latency and stale-answer problems.

Walking The Hierarchy

DNS is organized as a tree read from right to left. At the top are the root servers, which know where to find the servers for each top-level domain like com, org, or net. Below them, the top-level domain servers know which authoritative servers handle each registered domain. At the bottom, a domain's authoritative servers hold the actual records. When a recursive resolver has nothing cached, it starts at a root server, which points it to the relevant top-level domain servers. Those point it to the authoritative servers for the specific domain. Finally the authoritative server returns the real answer, such as the A record. Each step is a referral, narrowing the search by one level of the name. This hierarchy is what lets DNS scale to billions of names: no single server holds everything, and responsibility is delegated downward at each level.

Recursive Versus Iterative

The distinction between recursive and iterative queries trips up many engineers. When your application queries the recursive resolver, it asks a recursive question: please give me the final answer, doing whatever work is needed. The resolver accepts that responsibility. But the queries the resolver then makes to the root, top-level, and authoritative servers are iterative: each of those servers answers only with what it knows, either the final record or a referral pointing closer to the answer, and never chases the chain itself. So the recursive resolver is the only party that follows the whole path, asking one server, getting a referral, asking the next, and so on until it reaches the authoritative answer. This division keeps the root and top-level servers simple and fast, since they only ever hand out referrals rather than performing expensive multi-step lookups for every client on the internet.

Caching Makes It Fast

If every lookup walked the full hierarchy, DNS would be slow and the root servers would be overwhelmed. Caching prevents this. Every level caches: your operating system, the recursive resolver, sometimes your application runtime, and even the browser. When a resolver fetches an answer, it stores it and serves it directly to later requests for the same name until the answer expires. Because popular domains are queried constantly, their records live in caches almost everywhere, so a typical lookup completes in a millisecond or two from a nearby cache rather than after a round trip across continents. This is also why DNS-based changes do not take effect instantly worldwide. An old answer cached somewhere continues to be served until it expires, which is the source of the familiar advice to wait for propagation after changing a record. Caching is the trade between speed and freshness.

Understanding Time To Live

Every DNS record carries a time-to-live value, a number of seconds telling resolvers how long they may cache the answer before discarding it and asking again. The time-to-live is the single most important knob for controlling the trade-off between performance and agility. A long value, hours or a day, means excellent cache hit rates and minimal load on authoritative servers, but changes take that long to fully propagate as old answers slowly expire. A short value, seconds or minutes, lets changes take effect quickly, which is essential for failover and frequent address changes, but increases query volume and latency because caches expire constantly. A practical pattern before a planned migration is to lower the time-to-live well in advance, perform the change, then raise it again afterward, so the cutover propagates quickly while normal operation stays efficient.

DNS In Production Failures

DNS causes a disproportionate share of confusing outages because its failures rarely look like DNS failures. A service suddenly cannot reach its database, and the logs show connection errors, but the real cause is that resolution is returning stale or empty answers. Common culprits include a recursive resolver caching a now-incorrect address past a long time-to-live, a misconfigured record after a deploy, or a client runtime that caches a resolved address for its entire lifetime and never re-resolves even after the target moves. The classic Java behavior of caching DNS results indefinitely has bitten countless teams during failovers. Negative caching, where a not-found answer is itself cached, can prolong an outage after you fix a missing record. The practical lesson is to suspect DNS early, check what each layer is actually returning, and respect time-to-live in both directions.

DNS Over The Wire

Traditional DNS runs over UDP on port fifty-three, which suits it perfectly: queries and answers are small, a single datagram each, and the absence of a handshake keeps lookups fast. When a response is too large to fit, such as a long list of records or a signed response, the resolver retries over TCP, which is why DNS servers must support both. Classic DNS has a serious weakness: queries travel in plaintext, so anyone on the path can see which names you resolve and even tamper with answers. This drove two newer protocols, DNS over TLS and DNS over HTTPS, which wrap DNS queries in encryption to protect privacy and integrity. DNSSEC takes a different angle, cryptographically signing records so a resolver can verify an answer genuinely came from the authoritative source and was not forged, addressing authenticity rather than confidentiality.