What Is DNS? How the Domain Name System Works (2026)
Every DNS explainer calls it “the phone book of the internet.” That metaphor is accurate enough for a five-year-old but fails the moment you try to debug a misconfigured CNAME, understand why your DNS change is not propagating after 6 hours, or explain why a DNS amplification attack can take down a CDN. DNS is not a lookup table. It is a globally distributed, hierarchical, heavily cached database — and understanding those three properties explains almost every DNS behavior that seems mysterious at first.
The scale is worth stating explicitly: Cloudflare’s 1.1.1.1 resolver processes 4.3 trillion DNS queries per day as of 2025. ICANN reports 368.4 million registered domain names across all TLDs as of Q1 2025, with .com and .net alone accounting for 169.8 million. Every page load typically triggers 5–20 DNS lookups — for the main domain, CDN assets, analytics scripts, fonts, and API endpoints.
DNS was designed by Paul Mockapetris and Jon Postel in 1983 (formalized in RFC 882/883, then the current RFC 1034/1035 in 1987). The core protocol is unchanged. DNS over HTTPS (DoH, RFC 8484, 2018) and DNS over TLS (DoT, RFC 7858, 2016) are the most significant modern additions — they encrypt queries that have always been plaintext by default.
Key Takeaways
- ▸DNS is hierarchical: root nameservers → TLD nameservers → authoritative nameservers. Your resolver traverses this chain on a cache miss.
- ▸TTL controls propagation speed: lower TTL before DNS migrations (to 60–300s), raise it afterward (3600+). Lowering TTL has no effect if you do it the same day as the change.
- ▸CNAME cannot coexist with other records at the zone apex — you cannot have a CNAME for example.com (the root) alongside an MX record. Use ALIAS/ANAME or Cloudflare’s flattened CNAME to work around this.
- ▸DNS is plaintext by default — every query leaks the domain you are visiting to your ISP and any network observer. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt queries.
- ▸There are only 13 root nameserver IP addresses — but each is an anycast cluster of hundreds of physical servers worldwide. ICANN manages the root zone file.
The DNS Hierarchy: Four Levels
DNS is organized in a tree structure read right to left. The domain api.example.com. (note the trailing dot — the root) has four components:
| Level | Label in example.com. | Managed by | Count worldwide |
|---|---|---|---|
| Root zone | . (dot) | ICANN / IANA | 13 root server IPs (anycast clusters) |
| TLD | .com | Verisign (.com/.net), ICANN, registries | ~1,500 TLDs (gTLDs + ccTLDs) |
| Second-level domain | example | Domain registrant (you) | 368.4M registered domains (Q1 2025, per ICANN) |
| Subdomain | api, www, mail | Domain owner (DNS records) | Unlimited, defined in zone file |
A Complete DNS Lookup, Step by Step
When you type example.com into your browser and the answer is not cached anywhere, here is the exact sequence of 8 steps:
Browser checks its own cache
Chrome caches DNS responses for the duration of the TTL (or a minimum of 1 minute). If the record is cached and not expired, the lookup ends here — no network traffic at all.
OS checks its local resolver cache
The operating system maintains its own DNS cache (mDNSResponder on macOS, nscd or systemd-resolved on Linux, DNS Client service on Windows). Also checks /etc/hosts (or C:\Windows\System32\drivers\etc\hosts on Windows) for static overrides.
Query goes to the recursive resolver
The OS sends a UDP query (port 53) to the configured DNS resolver — typically your ISP's resolver, or a public resolver like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google). The resolver checks its own cache first.
Resolver queries a root nameserver
On a full cache miss, the resolver asks one of the 13 root nameserver addresses: "Who is authoritative for .com?" The root server responds with the IP addresses of .com's TLD nameservers — it does not know the answer, just who to ask next.
Resolver queries the TLD nameserver
The resolver asks a .com TLD nameserver: "Who is authoritative for example.com?" Verisign's servers respond with the NS records for example.com — the names of the domain's own nameservers.
Resolver queries the authoritative nameserver
The resolver asks example.com's authoritative nameserver (e.g., ns1.cloudflare.com) for the A record for example.com. This server holds the actual DNS records configured by the domain owner and returns the IP address.
Resolver caches the answer
The resolver caches the A record for the duration of its TTL. Subsequent queries from any client using this resolver will get the cached answer instantly — no traversal needed until the TTL expires.
Answer returned to browser
The resolver returns the IP address (e.g., 93.184.216.34) to the OS, which returns it to the browser. The browser caches it, then initiates a TCP connection (or QUIC for HTTP/3) to that IP on port 443.
The full traversal (steps 3–7) typically completes in 20–120ms depending on geographic proximity to the resolver and nameservers. Subsequent lookups hit the resolver cache and typically complete in 1–5ms. This is why DNS performance matters for page load times: a cold DNS lookup for each subdomain adds meaningful latency before any TCP connection is established.
DNS Record Types: Complete Reference
| Record | Purpose | Example value | Notes |
|---|---|---|---|
| A | Domain → IPv4 address | 93.184.216.34 | Most common record type |
| AAAA | Domain → IPv6 address | 2606:2800:220:1:... | Dual-stack — add alongside A |
| CNAME | Alias to another domain | www → example.com. | Cannot coexist at zone apex. No other records allowed on same name. |
| MX | Mail server for domain | 10 mail.example.com. | Priority number — lower = higher priority |
| TXT | Arbitrary text data | "v=spf1 include:..." | SPF, DKIM, domain verification (Google, GitHub) |
| NS | Authoritative nameservers | ns1.cloudflare.com. | Configured at registrar — delegates zone authority |
| SOA | Zone metadata | Serial, refresh, retry, expire, minimum TTL | One per zone — auto-managed by providers |
| PTR | Reverse DNS (IP → domain) | 34.216.184.93.in-addr.arpa. → example.com. | Configured by IP owner (ISP/cloud provider). Required for mail servers. |
| SRV | Service location and port | _https._tcp priority weight port target | Used by SIP, XMPP, Kubernetes service discovery |
| CAA | Restrict TLS certificate issuers | 0 issue "letsencrypt.org" | CAs must check before issuing — prevents rogue certs |
| ALIAS/ANAME | CNAME-like at zone apex | example.com → other.domain.com | Provider-specific (Cloudflare CNAME flattening, Route 53 ALIAS). Not an RFC standard. |
The CNAME-at-Apex Problem
RFC 1034 prohibits a CNAME record from coexisting with any other record on the same name. This means you cannot put a CNAME on your bare domain (example.com) because the zone apex requires NS and SOA records. This breaks a common use case: pointing your apex domain to a CDN or PaaS provider that only gives you a hostname, not an IP.
Solutions: Cloudflare CNAME Flattening resolves the CNAME to its IP at query time and serves an A record — invisible to clients. AWS Route 53 ALIAS records work similarly and are free (unlike standard Route 53 queries). Both are provider-specific extensions. Vercel, Netlify, and Render all document this issue in their custom domain setup guides.
TTL: Time to Live and DNS Propagation
“DNS propagation” is not a global broadcast — it is cache expiration. When you change a DNS record, existing cached answers persist until their TTL expires. A record with a TTL of 86400 (24 hours) will continue to be served by resolvers that cached it for up to 24 hours after you change it.
# View DNS records and their TTLs with dig
dig example.com A # A record
dig example.com MX # mail servers
dig example.com NS # nameservers
dig example.com TXT # TXT records
dig @8.8.8.8 example.com A # query a specific resolver (Google)
dig @1.1.1.1 example.com A # query Cloudflare's resolver
dig +short example.com A # just the IP(s), no extra output
# Check a specific nameserver directly (bypass cache)
dig @ns1.cloudflare.com example.com A
# Trace the full resolution chain
dig +trace example.com A
# Reverse DNS lookup (IP → domain)
dig -x 93.184.216.34
# View TTL in dig output:
# example.com. 300 IN A 93.184.216.34
# ^^^ TTL in seconds
# nslookup (available everywhere, less detail than dig)
nslookup example.com
nslookup example.com 8.8.8.8 # against specific resolver
# Flush local DNS cache (to test changes immediately)
# macOS:
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Windows:
ipconfig /flushdns
# Linux (systemd-resolved):
sudo systemd-resolve --flush-cachesTTL Strategy for DNS Migrations
The standard playbook for a zero-downtime DNS migration, based on Cloudflare’s infrastructure documentation:
DNS Security: DNSSEC, DoH, and Attack Vectors
DNSSEC: Cryptographic Validation
DNSSEC (DNS Security Extensions, RFC 4033–4035) adds digital signatures to DNS records. When a resolver receives a signed response, it can verify the signature using the zone’s public key — which is in turn signed by the parent zone, creating a chain of trust from the root. This prevents DNS cache poisoning (the Kaminsky attack, 2008), where an attacker injects forged records into a resolver’s cache.
According to APNIC’s DNSSEC statistics, roughly 30% of DNS queries globally are DNSSEC-validated as of 2025, up from 18% in 2021. Enable DNSSEC through your registrar and DNS provider — both must support it. Cloudflare, AWS Route 53, Google Cloud DNS, and most major registrars support DNSSEC with a one-click setup.
DNS Over HTTPS (DoH) and DNS Over TLS (DoT)
Traditional DNS uses UDP (and sometimes TCP) on port 53 — completely unencrypted. Your ISP, network admin, and any network observer can see every domain you look up. DoH (RFC 8484) wraps DNS queries in HTTPS, making them indistinguishable from regular HTTPS traffic. DoT (RFC 7858) uses TLS on port 853.
# DoH query with curl
curl -s -H 'accept: application/dns-json' 'https://1.1.1.1/dns-query?name=example.com&type=A' | jq .
# DoH query with dig (if compiled with DoH support, dig 9.17+)
dig +https @cloudflare-dns.com example.com A
# DoT query with kdig (knot-dns package)
kdig @1.1.1.1 +tls example.com A
# Configure system-wide DoH on Linux (systemd-resolved)
# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yesCommon DNS Attack Types
DNS Cache Poisoning
CriticalAn attacker sends forged DNS responses to a resolver before the legitimate response arrives, injecting a false IP for a domain. The resolver caches the forged record and serves it to all users. DNSSEC prevents this — signed records cannot be forged without the private key. The Kaminsky attack (2008) revealed a fundamental weakness in DNS that took years to fully patch.
DNS Amplification (DDoS)
HighAttacker sends DNS queries with a spoofed source IP (the victim's IP) to many open resolvers, requesting large DNS responses (ANY queries, DNSSEC responses). The resolvers send amplified responses (100:1 amplification ratio) to the victim. Cloudflare documented a 71 million RPS DDoS attack in 2023 that used DNS amplification as a component.
Subdomain Takeover
HighA CNAME record points to an external service (e.g., a Heroku, GitHub Pages, or Netlify app) that has since been deregistered. An attacker registers the same service name, claiming the subdomain. All traffic to your subdomain now goes to the attacker. Audit all CNAME records for targets that no longer exist.
DNS Hijacking
HighAttacker modifies DNS resolver configuration (compromising a home router, a corporate DNS server, or the DNS settings in your domain registrar account). All queries resolve to attacker-controlled IPs. Use DNSSEC and registrar account 2FA to mitigate.
DNS Providers: Comparing Performance and Features
According to DNSPerf’s global benchmarks (Q1 2026), the fastest authoritative DNS providers by median query time are Cloudflare (10ms), AWS Route 53 (15ms), Akamai Edge DNS (18ms), and Google Cloud DNS (19ms). For recursive resolvers, Cloudflare 1.1.1.1 consistently leads on latency, Google 8.8.8.8 leads on reliability. GoDaddy DNS leads by company count with 32.84% of the domain-name-services category globally, but lags significantly on performance.
| Provider | Type | Free tier | Notable features |
|---|---|---|---|
| Cloudflare DNS | Authoritative + Recursive | Yes (unlimited) | CNAME flattening, DDoS protection, DNSSEC, DoH/DoT, analytics |
| AWS Route 53 | Authoritative | $0.50/zone/mo | ALIAS records, health checks, routing policies (latency, geo, failover) |
| Google Cloud DNS | Authoritative | $0.20/zone/mo | DNSSEC, low latency, 100% uptime SLA |
| 1.1.1.1 (Cloudflare) | Recursive resolver | Free (public) | Fastest public resolver (DNSPerf), DoH/DoT, no-logging policy |
| 8.8.8.8 (Google) | Recursive resolver | Free (public) | Highly reliable, DoH/DoT support, 4.3T+ queries/day |
DNS for Developers: Common Configurations
# Typical DNS setup for a web application:
# Apex domain → server IP
example.com. 300 IN A 93.184.216.34
# www subdomain → apex (via CNAME or separate A)
www.example.com. 300 IN CNAME example.com.
# API subdomain
api.example.com. 300 IN A 93.184.216.34
# CDN via CNAME
static.example.com. 300 IN CNAME example.b-cdn.net.
# Mail configuration
example.com. 300 IN MX 10 mail.example.com.
mail.example.com. 300 IN A 198.51.100.10
# SPF record (who can send email as @example.com)
example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"
# DKIM (mail signing key — provider generates this)
google._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIj..."
# DMARC (mail policy)
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
# Domain verification for Google Search Console / GitHub, etc.
example.com. 300 IN TXT "google-site-verification=abc123..."
# CAA: only Let's Encrypt and Sectigo can issue TLS certs
example.com. 300 IN CAA 0 issue "letsencrypt.org"
example.com. 300 IN CAA 0 issue "sectigo.com"FAQ
What is DNS and why is it needed?
DNS translates domain names like example.com into IP addresses like 93.184.216.34 that computers use to route traffic. Without DNS, every user would need to memorize IP addresses for every site — and those IPs change when servers move. DNS is hierarchical, distributed, and cached at multiple levels to handle billions of queries per day at low latency.
What is the difference between a DNS resolver and an authoritative nameserver?
A recursive resolver is the server that does the lookup work on your behalf — it traverses the DNS hierarchy (root → TLD → authoritative) and caches results. An authoritative nameserver is the final source of truth for a specific domain — it holds the actual records configured by the domain owner. Resolvers cache answers; authoritative servers store the originals.
What DNS record types should every developer know?
Essential records: A (domain to IPv4), AAAA (domain to IPv6), CNAME (alias to another domain), MX (mail servers), TXT (SPF, DKIM, domain verification), NS (which nameservers are authoritative), SOA (zone metadata), CAA (restrict which CAs can issue TLS certs). ALIAS/ANAME records are provider-specific CNAME equivalents for use at the zone apex.
What is DNS TTL and how does it affect deployments?
TTL (Time to Live) tells resolvers how long to cache a DNS record in seconds. A TTL of 3600 = cached for 1 hour. Before a DNS migration, lower TTL to 60–300 seconds 24 hours in advance so changes propagate quickly. After migration is stable, raise TTL back to 3600+ to reduce resolver load.
What is DNS caching and how do I flush it?
DNS caching stores resolved records locally (in resolvers, OS, and browsers) for the TTL duration. Flush macOS cache: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder. Windows: ipconfig /flushdns. Linux (systemd-resolved): sudo systemd-resolve --flush-caches. Chrome: chrome://net-internals/#dns → Clear host cache.
What is DNSSEC and should I enable it?
DNSSEC adds cryptographic signatures to DNS responses, letting resolvers verify answers came from the real authoritative nameserver and were not tampered with in transit — preventing DNS cache poisoning. Enable it through your registrar and DNS provider (Cloudflare, Route 53, and most major providers support one-click setup). No application changes required.
What are common DNS attack types?
DNS cache poisoning injects forged records into a resolver's cache (DNSSEC prevents this). DNS amplification uses open resolvers to flood victims with large responses via a spoofed source IP — a common DDoS vector. Subdomain takeover occurs when a CNAME points to an expired/unclaimed external service an attacker re-registers. DNS hijacking redirects queries by compromising resolver or registrar account configuration.
Look Up Any Domain’s DNS Records
Use BytePane’s IP address and WHOIS tools to investigate any domain or IP, or dig deeper into networking concepts.