Turning Names into Addresses

IP addresses change. Companies move hosting providers. Servers get replaced. A name like api.myservice.com provides a stable identifier that can be pointed at whatever address is current. Your program connects to the name, DNS resolves it to an address behind the scenes, and the connection proceeds.

Without DNS, every configuration file, bookmark, and link would contain raw IP addresses. Changing a server’s address would break every client. DNS decouples the name from the address, and that indirection is what makes the internet manageable.

DNS is organized as a tree. At the top is the root, represented by a dot you rarely see. Below the root are the top-level domains (TLDs): com, org, net, uk, io, and hundreds of others. Below each TLD are the domains registered by organizations: example.com, mycompany.org. Those domains can contain further subdomains: api.mycompany.org, mail.mycompany.org.

When your program asks for the address of api.mycompany.org, the resolution proceeds through this tree:

This looks like a lot of round trips, but in practice most of them are skipped thanks to caching. The resolver almost certainly already knows the .org TLD servers. It might already have the authoritative servers for mycompany.org cached from a previous query. A full walk from the root happens rarely.

DNS does not just map names to addresses. A name can have several types of records associated with it, each serving a different purpose:

Your application code rarely deals with individual record types directly. When you resolve a hostname for a TCP connection, the system resolver queries A and AAAA records on your behalf and returns a list of addresses to try.

Every DNS response includes a time-to-live (TTL) value, measured in seconds. The TTL tells resolvers and clients how long they can cache the answer before asking again.

A TTL of 3600 means the answer is good for one hour. A TTL of 60 means it expires in a minute. Domain operators set the TTL based on how frequently the address might change. A stable website might use a TTL of 86400 (one day). A service that needs rapid failover might use a TTL of 30 seconds.

Caching is what makes DNS fast. Your first connection to api.mycompany.org triggers a real lookup, but subsequent connections within the TTL window use the cached result instantly. Your operating system maintains a local cache, your recursive resolver maintains a larger one, and intermediate resolvers along the chain do the same. By the time a popular domain’s record expires from one cache, it has already been refreshed by some other query.

The flip side is that changes do not take effect immediately. If a domain’s address changes, clients with a cached copy of the old answer continue using it until the TTL expires. This is why DNS propagation "takes time" — it is really just caches aging out.

Most DNS queries travel over UDP. A typical query and response fit within a single datagram, making UDP the natural fit: fast, no connection setup, minimal overhead. Port 53 is the standard port for DNS traffic.

When a response is too large for a single UDP datagram — which can happen with domains that have many records or with DNSSEC signatures — the server sets a flag indicating truncation. The client then retries the query over TCP, which can handle arbitrarily large responses by streaming the data.

The choice between UDP and TCP is handled automatically by the DNS resolver. Your application never needs to think about it.

Standard DNS maps a name to an address. A reverse lookup goes the other direction: given an IP address, it returns the associated hostname.

Reverse lookups use a special domain called in-addr.arpa for IPv4 (and ip6.arpa for IPv6). The IP address is written in reverse order and appended to this domain. To look up the name for 192.0.2.10, you query 10.2.0.192.in-addr.arpa and ask for its PTR (pointer) record.

Reverse lookups are not guaranteed to work. The owner of an IP address block has to set up PTR records deliberately, and many do not bother. They are mostly used for logging, diagnostics, and email server verification — not for establishing connections.

When your program resolves a hostname, the operating system performs the DNS lookup and returns a list of IP addresses. If the name has both A and AAAA records, you may get IPv4 and IPv6 addresses back. A well-written client tries them in order until one succeeds.

DNS failures are among the most common causes of connection errors. "Could not resolve host" means DNS returned nothing — either the name does not exist, the authoritative server is down, or the network path to the resolver is broken. Understanding the resolution chain helps you diagnose where the failure occurred.

DNS also explains behaviors that otherwise seem mysterious. A server migration that changes the IP address behind a name may take hours to propagate because caches hold onto the old answer until the TTL expires. A name that resolves fine from one machine but not another may be hitting different recursive resolvers with different cache states.

The next section looks at URLs — the format that combines a hostname, a port, and a resource path into a single string your program can act on.