DNS and IP Addresses: How a Domain Finds a Server

The short answer

DNS translates a name such as example.com into information a client can use—commonly one or more IP addresses. The browser can then use an address to begin a network connection.

DNS does not connect the browser, secure the connection, or request the web page. It answers a naming question. Connection establishment comes next.

Domain name versus URL versus IP address

These terms describe different things:

• A URL identifies a resource and includes parts such as a scheme, host, path, and query: https://example.com/products/42?currency=INR.
• A domain name is a name in the DNS hierarchy. In that URL, example.com is the domain used as the host.
• An IP address identifies a network interface for Internet Protocol routing, such as an IPv4 or IPv6 address.

The host in a URL can be a domain or an IP address. A domain can have several addresses, no web address record at all, or records for services other than the web. The WHATWG URL Standard defines how URLs, domains, and IP-address hosts are parsed.See the URL Standard’s host and URL sections.¹

Why DNS exists

Names are useful to people and applications because they can remain stable while infrastructure changes. Network packets, however, need addresses that routers can use. DNS provides the distributed naming layer between those concerns.

It also stores more than web-server addresses. DNS can declare which servers are authoritative for a zone, where mail should go, or arbitrary text used by domain policies and verification systems. That is why describing DNS as only “the Internet’s phone book” is incomplete: the directory contains several record types and delegates responsibility across many operators.

What checks may happen before an external lookup

Before a resolver walks the public hierarchy, several layers may already know the answer. A browser or operating system may retain recently used results. Local system configuration can override or supply names. The recursive resolver used by the device may also have a cached answer from an earlier client.

If a usable answer is cached, the lookup can finish there. That is the normal value of DNS caching: a popular name does not force every client request to revisit the root, top-level-domain, and authoritative servers.

Cached data has a lifetime, and implementations apply policy around it. The durable debugging question is: which layer supplied the answer this client is using? Two devices can temporarily see different results because their caches were populated at different times.

Recursive resolver

Most applications do not perform the entire hierarchy walk themselves. The operating system’s stub resolver sends a query to a recursive resolver, often operated by a network provider, an organization, or a public DNS service.

The recursive resolver takes responsibility for pursuing the answer. It first checks its cache. On a miss, it can send iterative queries to name servers and follow referrals. RFC 9499 distinguishes this recursive role from an authoritative server, which answers from zones for which it has authority.RFC 9499 defines current DNS resolver and authoritative-server terminology.²

Using a DNS provider for recursive resolution is different from using a DNS host for your domain’s authoritative records. One finds answers on behalf of clients; the other publishes the domain owner’s DNS data.

Root, TLD, and authoritative name servers

On a full cache miss, resolution follows delegation:

1. A root name server points the resolver toward the appropriate top-level domain, such as the servers responsible for .com.
2. A TLD name server points toward the authoritative name servers for example.com.
3. An authoritative name server answers from the relevant zone data, or indicates that the requested name or data does not exist.

The intermediate responses are usually referrals, not the final IP address. The resolver also caches useful referrals, so a later query under .com or the same domain may skip earlier steps.

RFC 1034 describes this hierarchy, delegation through name-server records, and resolvers following referrals.See RFC 1034’s name-server and resolver model.³ Modern DNS includes operational and security details beyond this beginner flow, but the division of responsibility remains useful.

DNS records

A DNS answer contains typed resource records. These six types are enough to understand many web incidents:

• A: associates a name with a 32-bit IPv4 address.
• AAAA: associates a name with a 128-bit IPv6 address.
• CNAME: identifies one domain name as an alias of another canonical name. The resolver may then need address records for that target.
• NS: identifies authoritative name servers for a zone or delegated part of the namespace.
• MX: identifies mail-exchange servers. It shows that DNS supports services beyond websites.
• TXT: carries text strings. It is widely used by email policy and domain-verification schemes, though DNS itself does not assign one universal application meaning to all TXT values.

RFC 1035 specifies A, CNAME, NS, MX, TXT, and the resource-record format.See RFC 1035’s resource-record definitions.⁴ AAAA was added for IPv6 by RFC 3596.RFC 3596 defines the AAAA record.⁵

A query asks for a specific name, record type, and class. Receiving an MX record does not make a web connection possible; a browser seeking an address normally needs usable A or AAAA information, potentially after following an alias.

DNS caching and TTL

Each DNS resource record carries a time to live, or TTL, measured in seconds. A resolver can cache that record for up to its remaining TTL rather than asking the authoritative system again. The remaining lifetime decreases while the record sits in cache.RFC 1035 defines the TTL field and cache lifetime.⁴

Caching makes DNS faster and reduces load, but it also means changes are not visible to every resolver at once. A resolver that cached an old address can continue returning it until the cached record expires. A resolver with no cached copy can retrieve the newer authoritative answer sooner.

TTL is not a promise that every client keeps a record for exactly that duration. Some answers are not cached, and resolvers may apply policy. Still, TTL is the main control published with the record for how long cached data may be reused.

IPv4 and IPv6

IPv4 addresses contain 32 bits and are commonly written as four decimal numbers, such as 192.0.2.10. IPv6 addresses contain 128 bits and use hexadecimal notation, such as 2001:db8::10. These examples come from documentation ranges; they are not service endpoints.

DNS uses A records for IPv4 and AAAA records for IPv6. A domain may publish one, the other, or both. It may also publish multiple addresses of either family. The client and network environment influence which usable result is selected and whether another address is tried after a failure.

An IP address is not necessarily a permanent identity for one application server. It might belong to an edge proxy or load balancer that represents many services, and it can change as infrastructure changes.

DNS and CDNs or load balancing

DNS can direct clients toward distributed infrastructure. A provider may return different addresses based on network location, service health, policy, or other inputs. A CNAME can delegate part of the resolution to a CDN-controlled name. Several A or AAAA records can also be returned for one name.

This does not mean DNS itself performs the later HTTP load-balancing decision in every design. The address can lead to a CDN edge, load balancer, or reverse proxy that makes additional routing decisions after a connection begins. Depending on the architecture, the address may represent an entry point rather than the final application process.

What “DNS propagation” actually means

People often say a DNS change is “propagating,” as though one new value is being copied outward through every DNS server. That wording hides two separate effects:

1. The authoritative DNS service may need time to make a change consistent across its own servers.
2. Recursive resolvers may continue serving older records they cached before the change, until those records expire.

DNS does not push every ordinary record update into every recursive cache. Resolvers fetch data when they need it and cache it according to the received lifetime. After a change, different clients can therefore see different answers without either client being permanently broken.

If name-server delegation changes, cached NS and related records add more boundaries to inspect. “Wait for propagation” is not a diagnosis; compare the answer from authoritative servers with the answer from the resolver used by the affected client.

Common misconceptions

Debugging scenario

Knowledge check

What to learn next

Deployment and Cloud Servers explains what can run behind the address DNS returns. Reverse Proxies, Logs, and Debugging Production Failures follows the request from that public entry point toward an upstream application.