How DNS Actually Works

DNS is the invisible foundation of every internet request, translating human-readable domain names into machine-readable IP addresses through a remarkable chain of distributed, hierarchical lookups. Understanding recursive resolution, caching, record types, and DNSSEC is essential for every developer who has ever debugged a mysterious outage.

The Question Every Internet Request Begins With

Every time you type a URL into your browser, send an email, or make an API call, the very first thing that happens is a DNS lookup. Before any data can flow, your computer needs to translate a human-readable name like www.example.com into a machine-readable IP address like 93.184.216.34. This translation is the Domain Name System (DNS), and it is one of the most critical pieces of internet infrastructure.

DNS is often called "the phone book of the internet," but that analogy undersells its complexity. DNS is a globally distributed, hierarchical, heavily cached database that handles trillions of queries per day with remarkable reliability. It was designed in 1983 by Paul Mockapetris (RFC 882 and RFC 883, later superseded by RFC 1034 and RFC 1035) and has scaled from a few thousand hosts to billions of devices with relatively few fundamental changes to its architecture.

Understanding how DNS works is essential for every developer. DNS misconfiguration is behind countless outages, performance problems, and security vulnerabilities. When DNS breaks, everything breaks.

The Resolution Process: Step by Step

When you type www.example.com into your browser, here is what actually happens:

Step 1: The Stub Resolver

Your operating system has a component called the stub resolver. It is deliberately simple: it takes a domain name, checks if it already knows the answer (from a local cache), and if not, forwards the query to a configured recursive resolver. The stub resolver does not do the heavy lifting of DNS resolution itself.

The recursive resolver's address is typically configured by your ISP (via DHCP) or explicitly set by you (to something like Google's 8.8.8.8, Cloudflare's 1.1.1.1, or Quad9's 9.9.9.9). Your choice of recursive resolver affects query performance, privacy, and security.

Step 2: The Recursive Resolver

The recursive resolver (also called a DNS recursor or caching resolver) is where the real work happens. It receives your query for www.example.com and, if it does not already have the answer cached, begins an iterative process to find it.

The recursive resolver starts at the top of the DNS hierarchy and works its way down, asking a series of questions that each narrow the search.

Step 3: Root Name Servers

The recursive resolver first contacts a root name server. There are 13 root server addresses (labeled A through M), but behind each address are hundreds of physical servers distributed globally via anycast routing. These are the starting point for all DNS resolution.

The root server does not know the IP address of www.example.com. But it knows where to find information about .com domains. It responds with a referral: "I do not know, but here are the authoritative name servers for the .com top-level domain."

Step 4: TLD Name Servers

The recursive resolver now contacts a .com TLD (Top-Level Domain) name server with the same question. The TLD server also does not know the final answer, but it knows which name servers are authoritative for example.com. It responds with another referral: "Here are the name servers for example.com."

Different TLDs are managed by different organizations. Verisign manages .com and .net. Various country-code registries manage their respective TLDs (.uk, .de, .jp). ICANN oversees the overall TLD system.

Step 5: Authoritative Name Servers

The recursive resolver contacts the authoritative name server for example.com. This is the server that actually has the DNS records for the domain. It looks up the record for www.example.com and returns the IP address.

The authoritative server is typically run by the domain owner directly, by their hosting provider, or by a managed DNS service (Cloudflare DNS, AWS Route 53, Google Cloud DNS).

Step 6: The Answer Returns

The recursive resolver receives the IP address, caches it (for the duration specified by the TTL), and returns it to your stub resolver, which caches it locally. Your browser now has the IP address and can establish a TCP connection to the web server.

This entire process typically takes 20-100 milliseconds for an uncached query. Cached queries resolve in under 1 millisecond.

Caching: Why DNS Is Fast

The resolution process described above involves 4 network round trips (to root, TLD, authoritative, and back). If every DNS query required all 4 trips, the internet would be noticeably slower. Caching makes DNS fast.

Recursive resolver cache: The recursive resolver (8.8.8.8, 1.1.1.1, your ISP's resolver) caches every response it receives. After resolving www.example.com once, it returns the cached answer for subsequent queries until the TTL expires. Popular domains are almost always cached.

Stub resolver cache: Your operating system caches DNS responses locally. On macOS and Linux, this is managed by the OS's resolver library. On Windows, the DNS Client service manages the cache.

Browser cache: Web browsers maintain their own DNS cache, separate from the OS cache. Chrome, Firefox, and other browsers cache resolutions to avoid even the overhead of a system call.

Negative caching: DNS also caches negative results. If you query a domain that does not exist (NXDOMAIN), the resolver caches this non-existence for the duration of the SOA record's minimum TTL. This prevents repeated queries for domains that will continue to not exist.

TTL: Time to Live

Every DNS record has a TTL value, expressed in seconds, that tells caching resolvers how long to keep the record before re-querying. TTL is the knob that controls the tradeoff between performance and freshness.

High TTL (e.g., 86400 seconds / 24 hours): Fewer DNS queries, better performance, reduced load on authoritative servers. But changes take up to 24 hours to propagate. Suitable for records that rarely change.

Low TTL (e.g., 60 seconds / 1 minute): Changes propagate quickly, enabling rapid failover and load balancing. But generates more DNS queries and increases resolution latency for cache misses. Suitable for records that change frequently or for services that need fast failover.

Zero TTL (0 seconds): The record should not be cached at all. Every query goes to the authoritative server. Useful for highly dynamic records but generates significant query volume. Note: some resolvers enforce a minimum TTL (e.g., 30 seconds) regardless of the record's setting.

Best practice for migrations: Lower the TTL well before making a change. If your TTL is 24 hours, reduce it to 5 minutes at least 24 hours before the migration. Make the change. After verifying it works, raise the TTL back to a higher value. This is the single most important DNS operational practice and the one most frequently forgotten.

DNS Record Types

DNS stores more than just IP addresses. Different record types serve different purposes.

A record: Maps a domain name to an IPv4 address. The most common record type. example.com -> 93.184.216.34

AAAA record: Maps a domain name to an IPv6 address. Same as A but for the 128-bit IPv6 address space. example.com -> 2606:2800:220:1:248:1893:25c8:1946

CNAME record: Creates an alias from one domain to another. www.example.com -> example.com. The resolver follows the CNAME to the target and resolves that. CNAMEs cannot coexist with other record types at the same name (a restriction that causes frequent confusion).

MX record: Specifies mail servers for a domain, with priority values. example.com MX 10 mail.example.com. Lower priority values are preferred. Email delivery depends entirely on correct MX records.

TXT record: Stores arbitrary text. Originally designed for human-readable notes, TXT records now carry machine-readable data for email authentication (SPF, DKIM, DMARC), domain verification (proving you own a domain to Google, AWS, etc.), and security policies.

NS record: Delegates a subdomain to specific name servers. The glue that connects the hierarchical delegation chain from root to TLD to authoritative.

SOA record: Start of Authority. Contains administrative information about the zone: the primary name server, the administrator's email, serial number, and timing parameters for zone transfers and caching.

SRV record: Specifies the hostname and port for a specific service. Used by protocols that need to discover services (like SIP, XMPP, and some Microsoft services). _http._tcp.example.com SRV 10 60 80 web.example.com

CAA record: Certificate Authority Authorization. Specifies which certificate authorities are allowed to issue certificates for the domain. A security measure that prevents unauthorized certificate issuance.

PTR record: Reverse DNS. Maps an IP address to a domain name. Used for email server verification and network diagnostics. 34.216.184.93.in-addr.arpa PTR example.com

DNSSEC: Securing the Chain

Standard DNS has no authentication. A resolver trusts whatever response it receives, creating opportunities for spoofing and cache poisoning attacks. An attacker who can inject a forged DNS response can redirect traffic to malicious servers.

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS responses. Each zone signs its records with a private key, and resolvers verify the signatures using the corresponding public key.

The trust chain works hierarchically, mirroring DNS delegation: 1. The root zone's public key is a trust anchor, hardcoded in resolver software 2. The root zone signs the .com zone's public key 3. The .com zone signs example.com's public key 4. example.com signs its own records

A resolver can verify the entire chain from root to leaf, ensuring that no records have been tampered with in transit.

DNSSEC adoption is growing but incomplete. As of 2026, approximately 30% of domains are signed, and roughly 30% of recursive resolvers validate DNSSEC signatures. The main barriers are operational complexity (key management, rotation, and the risk of signing errors that make your domain unresolvable) and the existence of alternative security measures (DNS over HTTPS, DNS over TLS) that protect the last mile without requiring zone signing.

DNS over HTTPS and DNS over TLS

Traditional DNS queries are sent in plaintext over UDP port 53. Anyone on the network path (your ISP, a coffee shop Wi-Fi operator, a government) can see which domains you are resolving. This is a privacy problem.

DNS over TLS (DoT) wraps DNS queries in TLS encryption, using port 853. The query format is unchanged; only the transport is encrypted. This prevents eavesdropping but is easy to block (just block port 853).

DNS over HTTPS (DoH) sends DNS queries as HTTPS requests to a standard web server on port 443. This is harder to block (because it looks like regular HTTPS traffic) and harder to distinguish from other web traffic. Major browsers support DoH natively.

Both DoT and DoH protect the path between your device and the recursive resolver. They do not protect the path between the resolver and authoritative servers (that is what DNSSEC addresses). The complete security picture requires both: DoH/DoT for privacy and DNSSEC for authenticity.

Common DNS Issues and Debugging

Propagation Delays

"DNS propagation" is a misnomer. DNS does not propagate like a broadcast. Changes are visible only after cached records expire (based on TTL). When you change a DNS record, some resolvers see the new value immediately (if they did not have it cached) while others see the old value until their cache expires. The maximum delay equals the previous TTL value.

Debugging Tools

dig: The standard DNS debugging tool. dig www.example.com performs a query and shows the full response, including the answer section, authority section, and timing information. dig +trace www.example.com shows the full resolution path from root to authoritative.

nslookup: A simpler alternative to dig, available on all platforms. nslookup www.example.com 8.8.8.8 queries a specific resolver, useful for comparing results across resolvers.

host: The simplest DNS lookup tool. host www.example.com returns just the answer. Useful for quick checks.

dog: A modern alternative to dig with colored output and a more intuitive interface.

Common Failure Modes

NXDOMAIN: The domain does not exist. Check for typos, verify the domain is registered, check that NS records are correctly configured.

SERVFAIL: The resolver encountered an error. Often caused by DNSSEC validation failures, misconfigured authoritative servers, or timeout issues. Try querying a different resolver to isolate the problem.

Timeout: The resolver did not receive a response. Check that your authoritative name servers are reachable, that port 53 (UDP and TCP) is open, and that the servers are responding within reasonable time.

Wrong answer: You get an IP address but it is the wrong one. Check for stale cached records, verify the record at the authoritative server directly (dig @ns1.example.com www.example.com), and look for CNAME chains that may point to unexpected destinations.

Slow resolution: If DNS is slow, check your resolver choice (switch to a well-connected public resolver like 1.1.1.1 or 8.8.8.8), verify that your authoritative servers have low response times, and consider whether your TTLs are too low (causing frequent re-resolution).

DNS as Infrastructure

DNS is deceptively simple on the surface and deeply complex underneath. It is the foundation that every internet service depends on, yet most developers only think about it when something goes wrong.

Understanding DNS resolution, caching behavior, record types, and security mechanisms is not just academic knowledge. It is the difference between a smooth migration and a multi-hour outage, between a secure application and a phishing-vulnerable one, between fast page loads and mysterious timeout errors.

The fundamental design of DNS, a hierarchical, heavily cached, distributed database with delegated authority, has proven remarkably durable. Designed for a network of thousands of hosts, it now serves billions. The core protocol is largely unchanged from 1987. Extensions (DNSSEC, DoH, DoT) address security and privacy concerns that the original designers could not have anticipated, but the basic architecture endures.

DNS is not glamorous. It is infrastructure in the truest sense: invisible when it works, catastrophic when it fails, and essential every single second of every single day.

DNS in Cloud and Modern Architectures

Modern cloud infrastructure has added new dimensions to DNS that every developer should understand.

Service discovery via DNS: Container orchestration platforms like Kubernetes and service meshes like Consul use DNS for service discovery. When a service named orders runs in Kubernetes, it is automatically reachable via orders.default.svc.cluster.local. This internal DNS is separate from public DNS but follows the same principles. Understanding DNS resolution behavior is critical for debugging connectivity issues in containerized environments.

Split-horizon DNS: Different answers for the same domain depending on who is asking. A corporate VPN might resolve internal.company.com to a private IP, while external users get a public IP or an NXDOMAIN. Cloud providers implement this via private hosted zones (AWS Route 53 Private Hosted Zones, GCP Cloud DNS Private Zones). Misconfigured split-horizon DNS is a common source of "works on my machine but not in production" bugs.

GeoDNS and latency-based routing: DNS can route users to the nearest server by returning different IP addresses based on the querier's location. AWS Route 53 supports geolocation routing, latency-based routing, and weighted routing, all via DNS. Cloudflare, Akamai, and other CDNs use similar techniques to direct users to the closest edge server.

DNS load balancing: Return multiple A records for the same domain, and clients will (roughly) distribute their connections across them. This is the simplest form of load balancing, requiring no special infrastructure. The downside: DNS has no health checking. If one server dies, DNS continues returning its IP until the record is updated. Managed DNS services add health checks to remove unhealthy endpoints automatically.

DNS as a single point of failure: Despite its distributed design, DNS can still be a single point of failure. If your authoritative DNS provider goes down, your domain becomes unreachable. The 2016 Dyn attack (a DDoS against a major DNS provider) took down Twitter, GitHub, Reddit, and dozens of other major services. Mitigation strategies include using multiple DNS providers simultaneously, keeping TTLs reasonable (not too low, which amplifies the impact of an outage), and considering whether your critical services can function with cached DNS records.

DNS prefetching: Modern browsers predict which domains you are likely to visit (based on links on the current page) and resolve them in advance. The <link rel="dns-prefetch" href="//api.example.com"> HTML tag hints to the browser that it should resolve a domain early. For performance-sensitive applications, DNS prefetching can shave 50-200ms off the first request to a third-party domain.

DNS and email deliverability: Email authentication relies heavily on DNS records. SPF (Sender Policy Framework) publishes authorized sending servers in a TXT record. DKIM (DomainKeys Identified Mail) publishes a public key in a TXT record for signature verification. DMARC (Domain-based Message Authentication, Reporting, and Conformance) publishes a policy in a TXT record for handling authentication failures. Incorrect DNS records for email authentication are the most common cause of emails landing in spam folders.

Understanding DNS at this depth transforms it from "that thing that sometimes breaks" into a powerful tool for traffic management, security, and operational resilience. The developers who invest in understanding DNS invariably find that it pays dividends across every system they build.