DNS Explained: How Domain Name Resolution Works

The Domain Name System translates human-readable domain names such as excellentwiki.com into machine-routable IP addresses. Without DNS, every internet user would need to memorize numerical addresses — an impossibility at internet scale. DNS is one of the oldest components of the internet protocol suite, first specified in RFC 882 and RFC 883 (1983) and later superseded by RFC 1034 and RFC 1035, which remain the core specifications. This guide covers DNS architecture, record types, resolution flow, caching, security extensions, and operational troubleshooting.

DNS Architecture

DNS is a hierarchical, distributed database. No single server holds the entire namespace. Instead, delegation chains from a set of root servers down through top-level domains to the authoritative nameservers for individual domains.

Root Servers

Thirteen root-server identities (lettered A through M) form the apex of the DNS hierarchy. Each identity is operated by a different organization — Verisign (A, J), USC-ISI (B), Cogent (C), University of Maryland (D), NASA (E), Internet Systems Consortium (F), US DoD (G), US Army (H), Netnod (I), RIPE NCC (K), ICANN (L), WIDE (M). Although there are only 13 logical root servers, anycast routing distributes them across hundreds of physical instances worldwide. Root servers do not resolve individual domain names; they answer queries for where the TLD nameservers are located.

Top-Level Domain Servers

TLD servers manage the next level of the hierarchy. Generic TLDs (gTLDs) include .com, .org, .net, .info, and newer gTLDs such as .blog, .app, .dev. Country-code TLDs (ccTLDs) include .uk, .de, .jp, .io. Each TLD operates a set of authoritative nameservers that know the delegation information for every domain registered under that TLD. Verisign operates both .com and .net under a cooperative agreement with ICANN.

Authoritative Nameservers

Authoritative nameservers hold the actual DNS resource records for a domain. When a domain owner updates an A record or adds an MX record, the change is published on the authoritative nameservers. Every domain must have at least two authoritative nameservers for redundancy (RFC 2182 recommends at least three geographically diverse servers). Authoritative servers can be primary (master) where zone data is edited and secondary (slave) that receive zone transfers via AXFR/IXFR (RFC 5936).

Recursive Resolvers

Recursive resolvers do the work of walking the delegation chain on behalf of clients. When you type a domain into a browser, the stub resolver in your operating system sends the query to a recursive resolver, typically operated by your ISP (e.g., Comcast 75.75.75.75), a public provider (Google 8.8.8.8, Cloudflare 1.1.1.1), or a corporate DNS server. The recursive resolver caches the answer and returns it to the client.

The Resolution Process

A complete DNS lookup follows this sequence:

1. The client queries the recursive resolver for www.example.com.
2. The resolver (if not already cached) queries one of the root servers. The root responds with the addresses of the .com TLD servers.
3. The resolver queries a .com TLD server. The TLD server responds with the addresses of example.com’s authoritative nameservers.
4. The resolver queries an authoritative nameserver for example.com. The authoritative server responds with the A or AAAA record for www.example.com.
5. The resolver caches the response according to the TTL and returns the result to the client.

For a cold cache, this process takes approximately 20-50 ms under normal conditions. Subsequent lookups for the same domain hit the resolver cache and complete in under 1 ms.

DNS Record Types

A and AAAA Records

A records (RFC 1035) map a hostname to a 32-bit IPv4 address. AAAA records (RFC 3596) map a hostname to a 128-bit IPv6 address. Most domains publish both for dual-stack resolution. The recursive resolver returns both types if the client requests them; modern operating systems prefer IPv6 (Happy Eyeballs algorithm, RFC 8305).

CNAME Records

CNAME records (canonical name) alias one domain to another. For example, www.example.com IN CNAME example.com tells resolvers to continue resolution using example.com. CNAMEs must not coexist with any other record type at the same name (RFC 1034 Section 3.6.2). The target of a CNAME should be an A or AAAA record.

MX Records

MX records (mail exchanger) specify the mail servers for a domain. Each MX record has a priority value: lower numbers are preferred. If the primary mail server is unreachable, senders fall back to the next-highest priority. Example:

example.com.  IN MX  10 mail.primary.example.com.
example.com.  IN MX  20 mail.secondary.example.com.

TXT Records

TXT records hold free-form text and are essential for email authentication and domain verification. SPF (RFC 7208) lists authorized outbound mail servers. DKIM (RFC 6376) publishes public keys for verifying email signatures. DMARC (RFC 7489) tells receivers how to handle unauthenticated mail. Domain verification records — random strings published as TXT records — prove ownership to certificate authorities and third-party services.

NS Records

NS records (nameserver) delegate a domain to its authoritative nameservers. They appear at the zone apex (e.g., example.com. IN NS ns1.provider.com.). Changing NS records effectively switches DNS providers; propagation can take 24-48 hours due to TTL caching at the TLD level.

SOA Records

The Start of Authority record (RFC 1035) contains administrative metadata: primary nameserver, responsible email, serial number (for zone transfer tracking), refresh interval, retry interval, expire time, and minimum TTL. The serial number must be incremented on every zone change.

DNS Caching and TTL

Time To Live values control how long a resolver caches a record. TTL is measured in seconds. Typical values: 300 (5 minutes) for records expected to change frequently, 86400 (24 hours) for stable records. Aggressive caching reduces resolver load and speeds responses but delays propagation after changes. The strategy of lowering TTL (to 60-300 seconds) 48 hours before a planned change is called TTL prep.

DNS Security

DNSSEC

DNS Security Extensions (RFC 4033, 4034, 4035) add cryptographic signatures to DNS records. A resolver that validates DNSSEC can verify that a response has not been forged. Each zone signs its records with a private key; resolvers validate using the public key published in DS (Delegation Signer) records in the parent zone. The chain of trust runs from the root (signed since 2010) down to the domain. DNSSEC adoption is roughly 30 percent for .com domains as of 2025 (ICANN data). Performance overhead: signing adds approximately 30-50 percent to response size, and validation takes 1-3 ms on a modern resolver.

DNS over HTTPS and DNS over TLS

Standard DNS (port 53, UDP) transmits queries and responses in cleartext. ISPs, Wi-Fi hotspot operators, and anyone with access to the network path can observe domain lookups. DNS over TLS (DoT, RFC 7858, port 853) and DNS over HTTPS (DoH, RFC 8484, port 443) encrypt the query channel, preventing eavesdropping and on-path tampering. Cloudflare 1.1.1.1, Google 8.8.8.8, and Quad9 9.9.9.9 all support both protocols. DoH has broader enterprise adoption because it uses port 443 and is harder to block than DoT.

Troubleshooting DNS

Common failure modes include: SERVFAIL (authoritative server misconfiguration or DNSSEC validation failure), NXDOMAIN (record does not exist), timeouts (unreachable resolver or authoritative server), and stale data (TTL not yet expired). The dig and nslookup tools are the primary diagnostic instruments. dig +trace walks the delegation chain step by step, revealing where resolution fails. The delv tool validates DNSSEC signatures explicitly.

FAQ

Q: What is the difference between a recursive resolver and an authoritative nameserver?
A: A recursive resolver accepts queries from clients and walks the DNS hierarchy to find answers. An authoritative nameserver holds the actual records for a specific domain and provides definitive answers. One organization manages recursive resolvers; the domain owner manages authoritative servers.

Q: How long does DNS propagation take?
A: Propagation is a misnomer — each resolver independently caches per TTL. The maximum propagation delay is the TTL on the changed record plus the TTL on the delegation (NS records). Practical maximum: 24-48 hours. Lowering TTL before changes reduces the delay to minutes.

Q: What is the difference between a CNAME and an ALIAS/ANAME record?
A: A CNAME cannot coexist with other records at the same name and requires an additional query. ALIAS (sometimes called ANAME or CNAME flattening) resolves at the authoritative server level and returns a native A/AAAA record to the resolver. ALIAS records can be placed at the zone apex where CNAMEs are forbidden by RFC.

Q: Is DNS over HTTPS slower than traditional DNS?
A: For the first query to a resolver, DoH may add 1-20 ms due to TLS handshake overhead. Subsequent queries reuse the TLS session and have negligible overhead. The privacy benefit usually outweighs the minor performance cost.

Q: What does the +CD flag in dig do?
A: +cd (checking disabled) tells the resolver to skip DNSSEC validation. It is useful for troubleshooting whether a SERVFAIL is caused by DNSSEC — if a query succeeds with +cd but fails without it, DNSSEC is the culprit.

Internal Links

• TCP/IP Protocol Suite Guide — how DNS fits into the internet protocol stack
• CDN Guide — how CDNs use DNS for request routing via anycast
• Network Troubleshooting — using dig/nslookup to diagnose network issues

References

• RFC 1034, “Domain Names — Concepts and Facilities”
• RFC 1035, “Domain Names — Implementation and Specification”
• RFC 4033, “DNS Security Introduction and Requirements”
• RFC 8484, “DNS Queries over HTTPS (DoH)”
• RFC 8305, “Happy Eyeballs Version 2”
• Kurose, J. F. and Ross, K. W., Computer Networking: A Top-Down Approach, 8th ed., Pearson, 2021, Section 2.4 (“DNS: The Internet’s Directory Service”)
• Tanenbaum, A. S. and Wetherall, D. J., Computer Networks, 6th ed., Pearson, 2021, Section 7.1 (“The Domain Name System”)

For a comprehensive overview, read our article on Cabling Standards.

For a comprehensive overview, read our article on Cdn Guide.