DNS and Name Resolution

Why This Matters

A single getaddrinfo("api.example.com", "443", ...) call can send a 33-byte DNS query over UDP/53, wait tens of milliseconds, and return several IPv4 and IPv6 addresses. If the answer is cached with TTL 300, the next call often returns from memory. If the cache is cold, the recursive resolver may perform three or more upstream lookups before the TCP connection to the service can even start.

DNS is also a failure amplifier. A stale CNAME, an expired negative cache entry, or an unreachable recursive resolver can make a healthy service look down. For ML systems, this shows up as slow first batch downloads, delayed model registry access, worker startup skew, and confusing errors where the application never reached the remote host.

Core Definitions

Hierarchical Names and Delegation

DNS names form a tree. The root is written as .. Top-level domains such as com, org, and edu sit below it. A registrable domain such as example.com sits below a TLD. Subdomains such as api.example.com and train.us-west.example.com sit below that domain.

Resolution follows delegation. The root zone does not store the A record for www.example.com; it stores NS records for com. The com zone stores NS records for example.com. The example.com authoritative servers store records such as A, AAAA, MX, TXT, CNAME, NS, and SOA.

A fully qualified domain name is encoded as length-prefixed labels on the wire. The name www.example.com. becomes these bytes in a DNS packet:

03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00
^  w  w  w  ^  e  x  a  m  p  l  e  ^  c  o  m  root

Each label length is one byte. The zero byte ends the name. Label length is limited to 63 octets, and the full domain name in wire format is limited to 255 octets.

Delegation data also has glue records. If example.com uses ns1.example.com as a name server, a resolver needs the address of ns1.example.com to ask it for example.com. The parent zone can include glue A or AAAA records with that referral.

Resource Records You Actually See

DNS data is stored as resource records. Records with the same owner name, class, and type form an RRset. DNSSEC signs RRsets, not individual records.

Common types:

• A maps a name to an IPv4 address, such as 93.184.216.34.
• AAAA maps a name to an IPv6 address, such as 2606:2800:220:1:248:1893:25c8:1946.
• CNAME makes one name an alias of another canonical name. A name with a CNAME cannot also have A, MX, or TXT records in the same zone data.
• MX names mail exchangers and includes a preference value. Lower preference wins.
• TXT stores arbitrary text strings. SPF, DKIM, and site verification often use TXT.
• NS names authoritative servers for a zone.
• SOA stores zone metadata, including serial, refresh, retry, expire, and negative-cache timing.

A small zone fragment looks like this:

example.com.        3600 IN SOA ns1.example.com. hostmaster.example.com. (
                         2026051101 7200 900 1209600 300 )
example.com.        3600 IN NS  ns1.example.com.
example.com.        3600 IN NS  ns2.example.net.
www.example.com.     300 IN A   93.184.216.34
www.example.com.     300 IN AAAA 2606:2800:220:1:248:1893:25c8:1946
api.example.com.      60 IN CNAME ingress.example.net.
example.com.        3600 IN MX  10 mail.example.com.
example.com.         300 IN TXT "v=spf1 include:_spf.example.net -all"

For api.example.com, a resolver must chase the CNAME and then look up address records for ingress.example.net. The returned answer may contain both the CNAME and the final A or AAAA records, but they are separate RRsets with separate TTLs.

Resolution Flow from Stub to Authoritative

Most application code does not build DNS packets. It calls libc or a language runtime, which uses a stub resolver. On Unix-like systems, the stub behavior is affected by /etc/hosts, /etc/nsswitch.conf, and /etc/resolv.conf.

A typical C lookup is small:

#include <netdb.h>
#include <stdio.h>
#include <arpa/inet.h>

int main(void) {
    struct addrinfo hints = {0}, *res, *p;
    char ip[INET6_ADDRSTRLEN];

    hints.ai_socktype = SOCK_STREAM;
    hints.ai_family = AF_UNSPEC;

    int rc = getaddrinfo("www.example.com", "443", &hints, &res);
    if (rc != 0) {
        fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(rc));
        return 1;
    }

    for (p = res; p; p = p->ai_next) {
        void *addr = p->ai_family == AF_INET
            ? (void *)&((struct sockaddr_in *)p->ai_addr)->sin_addr
            : (void *)&((struct sockaddr_in6 *)p->ai_addr)->sin6_addr;
        inet_ntop(p->ai_family, addr, ip, sizeof ip);
        puts(ip);
    }

    freeaddrinfo(res);
    return 0;
}

If /etc/hosts contains 203.0.113.10 www.example.com, many systems return that address before querying DNS. A common nsswitch.conf line is hosts: files dns, meaning the files source is checked before DNS.

When DNS is used, the flow for www.example.com A is:

1. Application calls getaddrinfo.
2. Stub resolver asks a configured recursive resolver.
3. Recursive resolver asks a root server for www.example.com A.
4. Root replies with a referral to com name servers.
5. Recursive resolver asks a com TLD server.
6. TLD replies with a referral to example.com name servers.
7. Recursive resolver asks an authoritative server for example.com.
8. Authoritative server returns the A RRset or an error.
9. Recursive resolver caches and returns the result to the stub.

On a warm cache, steps 3 through 8 can disappear. If the recursive resolver already has the com NS RRset and the example.com NS RRset, it can go straight to an authoritative server. If it already has the A RRset, it can answer immediately.

A minimal DNS query for www.example.com A IN can be shown as hex:

12 34 01 00 00 01 00 00 00 00 00 00
03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00
00 01 00 01

Header bytes:

12 34       transaction ID
01 00       flags, recursion desired set
00 01       QDCOUNT = 1
00 00       ANCOUNT = 0
00 00       NSCOUNT = 0
00 00       ARCOUNT = 0

The final four bytes are QTYPE 00 01 for A and QCLASS 00 01 for IN.

Transport Choices and Encrypted DNS

Classic DNS uses UDP/53 for queries because a single request usually fits in one packet. The response carries the same transaction ID. If the response is too large, the server sets the TC flag, and the client retries over TCP/53. TCP is also used for zone transfers and for responses made large by DNSSEC records.

EDNS(0) lets clients advertise a larger UDP payload size than the original 512-byte limit. Large UDP responses still risk fragmentation or filtering, so production resolvers need correct TCP fallback.

DNS over TLS uses TCP port 853. It wraps DNS messages in TLS with a two-byte length prefix before each DNS message. DNS over HTTPS sends DNS messages inside HTTPS, usually over port 443. DoT and DoH hide DNS content from passive observers between the client and the resolver, but the resolver still sees the query unless additional privacy systems are used.

dig makes transport visible:

dig www.example.com A
dig +tcp www.example.com A
dig @1.1.1.1 www.example.com AAAA
dig +trace www.example.com A
drill -T www.example.com A

dig +trace performs iterative-style tracing from the root, which is useful for delegation bugs. It is not exactly the same as the query path of your machine's configured recursive resolver, because it bypasses that resolver's cache.

Caching, TTLs, and Negative Answers

Every layer can cache. Browsers may cache DNS answers. Language runtimes may cache. The operating system or a local daemon such as systemd-resolved may cache. The recursive resolver caches positive and negative responses. Authoritative servers do not cache their own zone data, but they publish TTLs.

TTL arithmetic is simple but operationally sharp. Suppose api.example.com A has TTL 60. The recursive resolver receives it at time 1000. It can return it until time 1060. At time 1045, it should return TTL 15. If a local OS cache stores that response at time 1045, that local cache should expire it at time 1060, not time 1105.

Negative caching stores proof that a name or type does not exist. NXDOMAIN means the domain name does not exist. NODATA means the name exists but has no RRset of the requested type. RFC 2308 defines negative caching using SOA data. Many resolvers cap negative TTLs, but the effective bound comes from the SOA negative TTL and local policy.

Example:

missing.example.com.  A  -> NXDOMAIN
authority section:
example.com. 300 IN SOA ns1.example.com. hostmaster.example.com. 2026051101 7200 900 1209600 300

The recursive resolver can cache the NXDOMAIN for about 300 seconds. If you create missing.example.com one minute later, clients using that resolver may still fail for four more minutes.

The Model

A resolver is a state machine over three data sources: local host databases, a cache indexed by question or RRset, and network queries to upstream DNS servers. The useful invariant is time boundedness.

For a positive RRset received at time $t_0$ with TTL $T$, a cache may return it at time $t$ only if $0 \leq t - t_0 < T$. The TTL sent downstream is at most $T - (t - t_0)$.

For a CNAME chain, each RRset has its own expiry. If a.example CNAME has TTL 300 and b.example A has TTL 20, the usable combined answer expires in 20 seconds unless the A RRset is refreshed. The chain validity is bounded by the minimum remaining TTL:

For negative answers, cache lifetime is bounded by the negative caching TTL selected from the SOA data and resolver policy:

DNSSEC adds authenticity, not secrecy. The chain of trust starts from a configured root trust anchor, validates DS and DNSKEY records down the delegation path, and then validates signatures over RRsets. If validation fails, a validating resolver returns failure rather than unsigned data. This page does not cover the signature algorithms or canonicalization rules.

Common Confusions

Exercises

References

Canonical:

• Stevens and Fall, TCP/IP Illustrated, Volume 1: The Protocols (2nd ed., 2011), ch. 11 — DNS message format, resolver behavior, and name resolution examples
• Tanenbaum and Wetherall, Computer Networks (5th ed., 2011), §7.1 — DNS namespace, resource records, and name servers
• Stevens, Fenner, and Rudoff, UNIX Network Programming, Volume 1 (3rd ed., 2004), ch. 11 — getaddrinfo, address conversion, and resolver-facing APIs
• Mockapetris, RFC 1034, Domain Names: Concepts and Facilities (1987), §§3-5 ; DNS namespace, zones, and resolvers
• Mockapetris, RFC 1035, Domain Names: Implementation and Specification (1987), §§3-4 ; resource records and DNS packet format
• Andrews, RFC 2308, Negative Caching of DNS Queries (1998), §§2-5 ; NXDOMAIN, NODATA, and negative TTL behavior
• Arends et al., RFC 4033, DNS Security Introduction and Requirements (2005), §§2-5 ; DNSSEC trust chain and validation model

Accessible:

• Zytrax, DNS for Rocket Scientists ; practical explanation of zones, records, delegation, and diagnostic commands
• Julia Evans, How DNS Works ; compact operational guide with resolver and cache diagrams
• ISC, BIND 9 Administrator Reference Manual ; operational reference for authoritative and recursive server behavior

Next Topics

• /computationpath/tcp-connection-lifecycle
• /computationpath/tls-handshake
• /computationpath/http-request-lifecycle
• /computationpath/load-balancing-and-service-discovery