DNS Resolution

The Domain Name System (DNS) is a distributed, hierarchical database that maps domain names (such as www.example.com) to data, most often IP addresses. Clients need an IP address to open a connection, so almost every request to a service begins with a DNS lookup. DNS is also a system design tool: it directs traffic to regions, load balancers, and CDNs.

The hierarchy

A domain name is read right to left. Each dot-separated label is a level in a tree.

• Root zone (.): served by 13 named root server identities (a.root-servers.net to m.root-servers.net), each implemented by many machines using anycast.
• Top-level domain (TLD): com, org, net, country codes such as de.
• Second-level domain: example.com, registered by an owner.
• Subdomains: www.example.com, api.example.com, controlled by the owner of the parent domain.

A zone is a portion of the tree managed by one set of authoritative name servers. Authoritative servers hold the actual records for a zone and give definitive answers. A parent zone delegates a child zone by publishing NS records that name the child's name servers. If the name server lies inside the delegated zone itself (for example ns1.example.com serving example.com), the parent zone also publishes a glue record: the A or AAAA record of that name server. Without glue, the resolver would need to resolve ns1.example.com before it could ask the server that knows example.com, which is circular.

Recursive and iterative resolution

Two kinds of servers take part:

• A recursive resolver (for example the resolver run by an ISP, or a public resolver) accepts a query from a client and does the work of finding the answer. It caches results.
• Authoritative servers answer only for their own zone, or refer the caller to a more specific server.

The client (a stub resolver in the operating system) sends one query to the recursive resolver. This is a recursive query. The resolver then sends iterative queries to authoritative servers: each server either answers or returns a referral to the next server down the hierarchy.

sequenceDiagram
    participant C as Client (stub resolver)
    participant R as Recursive resolver
    participant Root as Root server
    participant TLD as .com TLD server
    participant Auth as example.com authoritative server
    C->>R: A www.example.com?
    R->>Root: A www.example.com?
    Root-->>R: Referral: NS for com
    R->>TLD: A www.example.com?
    TLD-->>R: Referral: NS for example.com
    R->>Auth: A www.example.com?
    Auth-->>R: A 203.0.113.10, TTL 300
    R-->>C: A 203.0.113.10

If the resolver has the answer cached, it replies immediately. If it has only the NS records for com cached, it skips the root query. In practice most lookups hit the cache and the root servers see a small share of total traffic.

Classic DNS uses UDP on port 53. The original limit for a UDP response is 512 bytes, and the EDNS0 extension lets clients advertise larger sizes. When a response does not fit, the server sets the truncation (TC) flag and the client repeats the query over TCP on port 53. Newer transports encrypt queries: DNS over TLS (port 853) and DNS over HTTPS.

Record types

Constraints worth knowing:

• A CNAME cannot coexist with other record types at the same name. Because the zone apex (example.com) must hold SOA and NS records, a CNAME cannot be placed at the apex. DNS providers work around this with proprietary "alias" or "CNAME flattening" features that resolve the target on the server side.
• A resolver that meets a CNAME restarts the lookup for the target name, which can add a query. For example, www.example.com CNAME example.cdn.net requires a second lookup of example.cdn.net for its A record, and each hop in a chain of aliases can add another.

Caching and TTL

Every record carries a time to live (TTL) in seconds. A resolver may cache the record for at most that long and must then query again.

Caching occurs at several layers: the browser, the operating system, the recursive resolver, and sometimes an intermediate forwarder. Consequences:

• Low TTL (for example 30 to 60 seconds): changes propagate quickly and failover is fast, but the resolver sends more queries and lookups are slower on cache misses.
• High TTL (hours): fewer queries and lower latency, but changing a record takes as long as the old TTL to take effect everywhere.
• Negative caching: a response saying a name does not exist (NXDOMAIN) is also cached, for a duration taken from the zone's SOA record.
• Some clients and resolvers ignore or clamp TTLs. A TTL is therefore a request, not a guarantee, and a failover plan should not assume every client switches exactly when the TTL expires.

Worked example: a record has TTL 86400 (24 hours). If the address is changed at 12:00, a resolver that cached the old answer at 11:59 keeps serving it until 11:59 the next day, so some clients reach the old address for almost a full day. With TTL 60, the same window is at most one minute.

A common migration procedure: lower the TTL well before a planned change (at least one old TTL in advance), make the change, and raise the TTL again afterwards.

DNS-based load balancing

An authoritative server can return several records for one name.

• Round-robin DNS: multiple A records for a name. The server rotates the order, and clients typically use the first address. It needs no extra infrastructure but has weaknesses: the server does not know which backends are healthy, cached answers pin clients to one address for the TTL, and the distribution follows resolvers rather than individual clients, so load can be uneven.
• Health-checked DNS: the DNS provider probes endpoints and removes failed ones from answers. Failover speed is bounded by the TTL plus caching behavior of clients.
• Weighted records: the server returns each address in proportion to a configured weight, used for gradual traffic shifts.

DNS is typically used to distribute traffic between a few large endpoints (regions, load balancer clusters), and a load balancer then distributes to individual servers.

GeoDNS and latency-based routing

GeoDNS returns different answers depending on where the query appears to come from. The authoritative server sees the address of the recursive resolver, not the client, so it maps the resolver's location to a region. The EDNS Client Subnet extension lets a resolver pass a truncated client prefix to the authoritative server for a more accurate decision, at the cost of reduced cache sharing and some privacy exposure.

Variants:

• Geolocation routing: answer by country or continent (also used for data residency rules).
• Latency-based routing: answer with the region measured to have the lowest latency from the resolver's network.
• Anycast: several servers announce the same IP address through BGP and the network routes each client to a nearby one. Root servers and many public DNS services and CDNs use it.

flowchart LR
    U1["Client in Europe"] --> R1["Resolver in Europe"]
    U2["Client in Asia"] --> R2["Resolver in Asia"]
    R1 --> A["Authoritative DNS with geo policy"]
    R2 --> A
    A -->|"198.51.100.1"| EU["EU region endpoint"]
    A -->|"192.0.2.1"| AS["Asia region endpoint"]

Failure modes and trade-offs

• Stale caches keep clients on a failed address until the TTL expires.
• Resolver outage: if a client's resolver is down, no names resolve even though the service is healthy. Clients usually configure several resolvers.
• Authoritative outage: DNS providers run many servers with anycast, and zones are often served by more than one provider for redundancy.
• Cache poisoning: a forged response accepted by a resolver redirects users. Mitigations include random source ports and query IDs, and DNSSEC, which signs records so resolvers can verify authenticity.
• Extra latency: a cold lookup can require several round trips before the first byte of the actual request. Mitigations are long TTLs for stable names, fewer distinct hostnames per page, and DNS prefetching.

Interview questions

• What happens when you type a URL into a browser, as far as DNS is concerned? The browser and OS check their caches, then the stub resolver asks the configured recursive resolver. On a miss, the resolver queries root, TLD, and authoritative servers iteratively, caches the answer for its TTL, and returns the IP address to the client.
• Why can DNS not provide instant failover? Resolvers and clients cache records for the TTL, and some clamp it. Lowering the TTL shortens the window but does not remove it and raises query volume.
• How does a CDN direct users to a nearby edge server? Either through DNS answers that depend on the resolver's location or measured latency, or through anycast, where the same IP is announced from many locations and routing selects a nearby one.
• Why can a CNAME not be used at the zone apex? A CNAME means the name is an alias for another name and must be the only record at that name, but the apex must also carry SOA and NS records.