DNS — deep dive

Status: 🟩 COMPLETE Last updated: 2026-06-19 Plain-English tagline: The protocol-level view of DNS — how a name like stmarkbible.com becomes an IP, who answers the question, what gets cached where, and why “propagation” takes a day.

In plain English

You’ve seen DNS from the hosting side: A records, CNAMEs, TXT records, how to point a domain at Vercel. That’s Domains and DNS. This entry is the LAYER below — what DNS actually IS as a network protocol:

A hierarchical, globally-distributed database
Queried over UDP port 53 (sometimes TCP)
Answered by a chain of nameservers, each authoritative for a slice of the namespace
Cached aggressively at multiple layers (your laptop, your router, your ISP, intermediate resolvers)
Standardized in RFCs from 1987 onwards, still mostly the same protocol

The whole internet relies on DNS continuously. Every browser tab makes dozens of DNS queries (one per third-party resource). Every API call. Every email send. DNS is the silent infrastructure that nobody thinks about until it breaks.

This entry covers the wire-level mechanics: how a query travels, who answers, why caching is everywhere, and why a DNS change can take 48 hours to propagate globally despite TTLs that say 5 minutes.

For configuration (setting records in Vercel, GoDaddy, Cloudflare), see Domains and DNS.

Why it matters

Three concrete reasons protocol-level DNS knowledge pays off:

Debugging “why isn’t my domain working” requires it. DNS is multi-layered: registrar, nameservers, records, caches. Knowing where to look saves hours when changes don’t take effect.
TTLs and propagation make sense once you see the caching chain. “Why does my TTL of 60 seconds not work?” → because intermediate caches lie. “Why does a change still appear for some users?” → because their resolver still has the old answer cached.
Modern variants (DoH, DoT, DNSSEC, ECH) make sense from this base. They’re variations on the same protocol; understanding the base makes the variants tractable.

The trade-off: DNS is mature (40+ years) and quirky. Mastery comes slow. For typical webapp work, the level in this entry is “good enough” — you can debug everything DNS-related but you’re not running your own authoritative server.

The hierarchy — how the namespace is organized

DNS is a TREE. The root is . (the dot). Below it: top-level domains (TLDs) like .com, .org, .au. Below those: second-level domains like stmarkbible.com. Below those: subdomains like www.stmarkbible.com.

Reading right to left:

www.stmarkbible.com.
└┬─┘ └─────┬───── └┬┘
 |           |       └── root (the trailing dot, usually omitted)
 |           └── TLD (.com)
 └── owned domain (stmarkbible)
└── subdomain (www)

Each level is managed by a DIFFERENT authority:

The root is managed by ICANN; its nameservers are 13 globally distributed clusters (a.root-servers.net through m.root-servers.net)
Each TLD (.com, .org, .au, etc.) is managed by a registry (Verisign for .com, PIR for .org, etc.)
Each second-level domain is managed by whoever registered it, via the nameservers they designated (often the registrar’s default nameservers, or Cloudflare, or Vercel, etc.)

This delegation is THE killer feature: ICANN doesn’t need to know about every subdomain.example.com in the world. They just need to know “if asked about .com, here’s where to ask next.” That delegation cascade is what makes DNS scale.

A full DNS query, step by step

You type stmarkbible.com into a browser. Here’s what happens:

Step 1: Browser cache
  "Have I asked about stmarkbible.com recently?" → no, or expired.

Step 2: OS cache
  Browser asks the operating system; OS checks its DNS cache. → no.

Step 3: Resolver (your ISP or 1.1.1.1 / 8.8.8.8)
  OS sends a UDP query to its configured recursive resolver:
    "What's the IP of stmarkbible.com?"

Step 4: Resolver checks ITS cache
  → cache miss. Begins recursive resolution.

Step 5: Resolver asks a root nameserver
  "Where do I find .com?"
  Root: "Ask the .com TLD nameservers at these IPs..."

Step 6: Resolver asks a .com nameserver
  "Where do I find stmarkbible.com?"
  .com TLD: "stmarkbible.com's authoritative nameservers are at ns1.vercel-dns.com / ns2.vercel-dns.com (and here are their IPs)"

Step 7: Resolver asks Vercel's nameserver
  "What's the A record for stmarkbible.com?"
  Vercel NS: "It's 76.76.21.21" (with a TTL)

Step 8: Resolver caches the answer + returns to OS
Step 9: OS caches + returns to browser
Step 10: Browser opens TCP connection to 76.76.21.21

That’s a full “cache-miss” resolution. Usually 30-200ms end-to-end.

On a cache HIT (any layer above the chain), the response is near-instant — single-digit milliseconds.

The three layers of caching

Every DNS query passes through:

1. Application cache (browser, app)

The browser maintains a short-lived DNS cache (~60s on Chrome, varies). Repeated requests within the same tab session don’t even hit the OS.

2. OS resolver cache

Windows, macOS, Linux all maintain a per-system DNS cache. TTL-aware. Cleared by:

ipconfig /flushdns (Windows)
sudo dscacheutil -flushcache (macOS)
sudo systemd-resolve --flush-caches (Linux)

3. Resolver cache (your ISP / Cloudflare / Google)

The recursive resolver — usually your ISP’s 8.8.8.8 (Google), 1.1.1.1 (Cloudflare) — keeps a massive cache. When you ask, you’re often getting THEIR cached answer, not the authoritative one.

Optional: Intermediate caches

Some networks have additional caching DNS resolvers between your machine and the public resolver. Corporate networks especially.

Each layer’s TTL controls how long it caches. A resolver might honor a 60-second TTL, but some ISPs cap TTL at 1 hour to reduce load — meaning your 60-second TTL is effectively 1 hour for users on that ISP.

This is why “DNS propagation” can take 1-48 hours in the worst case despite published TTLs being short.

DNS record types — the wire format

The wire format of a DNS message is: question(s) and answer(s), with record types determining what each answer looks like.

The record types you’ll meet:

Type	What it stores	Example
A	An IPv4 address	`stmarkbible.com A 76.76.21.21`
AAAA	An IPv6 address (“quad-A”)	`stmarkbible.com AAAA 2606:4700::1`
CNAME	An alias to another name	`www.stmarkbible.com CNAME stmarkbible.com`
NS	Nameservers authoritative for this zone	`stmarkbible.com NS ns1.vercel-dns.com`
MX	Mail servers for this domain	`stmarkbible.com MX 10 mail.google.com`
TXT	Free text — used heavily for verification (SPF, DKIM, DMARC)	`stmarkbible.com TXT "v=spf1 include:_spf.google.com ~all"`
CAA	Which certificate authorities can issue certs for this domain	`stmarkbible.com CAA 0 issue "letsencrypt.org"`
SOA	Start of Authority — admin info, refresh timing	Internal; rarely manually edited
PTR	Reverse — IP to name lookup	Managed by your IP owner (ISP/cloud)
SRV	Service record (port + host for a specific service)	Rare in web work
DNSKEY / DS / RRSIG	DNSSEC signing	If you’ve enabled DNSSEC

A DNS query specifies a NAME + TYPE. The response is a list of matching records.

Query:    stmarkbible.com A
Response: stmarkbible.com 3600 IN A 76.76.21.21
                          ↑                ↑
                          TTL              IPv4 address
                              ↑
                              "Internet class" (always IN)

TTL — Time To Live

Every record has a TTL: how long resolvers should cache it before refetching from authority.

TTLs are advisory — resolvers can ignore them (some do, especially older ISPs). But honored TTLs:

0 — don’t cache (rare; valid)
60 — 1 minute (used for fast-changing records)
300 — 5 minutes (low; used for “I might need to change this soon”)
3600 — 1 hour (common default)
86400 — 24 hours (high; used for stable records)
604800 — 1 week (very high; some registrars default here)

Pattern for changing a record:

Lower TTL to 300 a day or two BEFORE the change
Wait for old TTL to expire (so caches refresh with the new short TTL)
Make the change
Most caches refresh quickly because they have the new short TTL
After stable, raise TTL back to normal

This is “preparing for migration” — without it, a change with a 24-hour TTL takes up to 24 hours per cache to propagate.

The propagation problem

“DNS propagation” isn’t really propagation — DNS doesn’t push updates. It’s CACHE EXPIRATION.

When you change an A record:

Your nameserver immediately serves the new value
Caches around the world keep serving the OLD value until their TTL expires
Cache expires → resolver asks your nameserver again → gets the new value → caches that

Worst-case time: the longest TTL among caches plus their own re-fetch delay. With a 1-hour TTL, expect 1-3 hours for most users; with a 24-hour TTL, expect 24-48 hours for the long tail.

Use dnschecker.org to see how the record looks from different geographic resolvers.

Authoritative vs recursive nameservers

A subtle but important distinction:

Authoritative nameservers are the source of truth for a specific domain. Vercel’s ns1.vercel-dns.com is authoritative for any domain whose owner has configured Vercel’s nameservers. The authoritative answer for stmarkbible.com A lives there.

Recursive resolvers are the ones YOU query. They don’t host records themselves; they walk the delegation chain (root → TLD → authoritative) and cache the answer.

When you set up your domain:

Your registrar is where you bought the name (Namecheap, GoDaddy, Vercel Domains, Cloudflare Registrar)
Your nameservers are where the records live (often the registrar’s default, sometimes Cloudflare’s, sometimes the host’s)
Your resolver is something you, the user, query (usually your ISP’s, or Google’s 8.8.8.8, or Cloudflare’s 1.1.1.1)

The chain from “user types domain” to “user gets IP” involves all three. Each is configured separately.

DNS over UDP and TCP

DNS is mostly UDP on port 53 — single packet there, single packet back, very fast.

But DNS uses TCP on port 53 when:

The response is too big for UDP (over ~512 bytes traditionally; ~1232 bytes in modern EDNS0)
A zone transfer happens (AXFR, IXFR)
DNSSEC signatures inflate the response size

Modern DNS often uses EDNS0 (Extension Mechanisms for DNS) to negotiate larger UDP packets (up to 4096 bytes). Reduces TCP fallback frequency.

DNSSEC — signed records

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. Lets resolvers verify “this answer really came from the authoritative server; nobody tampered.”

Without DNSSEC, a network attacker could intercept your DNS query and respond with a fake IP, redirecting you to a malicious server. DNSSEC prevents this.

Practical reality in 2026:

~30% of domains have DNSSEC enabled (rising but slow)
Some TLDs (.gov, .nl, .se) have DNSSEC enabled by default
Major resolvers (1.1.1.1, 8.8.8.8) validate DNSSEC signatures
DNSSEC adds complexity to domain transfers; many small projects skip it

For Bible Quest: DNSSEC is optional and adds operational risk (if signing keys are misconfigured, the domain goes dark). The playbook doesn’t require it.

DoT, DoH — encrypted DNS

Traditional DNS is PLAINTEXT. Your ISP, anyone on your WiFi, can see every domain you visit (the DNS query is unencrypted even though the actual HTTPS traffic is encrypted).

Two solutions for privacy:

DoT (DNS over TLS) — port 853, TCP, encrypted via TLS. Server (e.g., 1.1.1.1) needs to support it.
DoH (DNS over HTTPS) — DNS queries inside an HTTPS POST. Indistinguishable from regular web traffic.

Modern browsers (Chrome, Firefox) use DoH by default in some regions. The browser bypasses the OS resolver and queries a known DoH endpoint directly (typically Cloudflare or Google).

Implications:

Your DNS queries are private from intermediate networks
The DoH provider sees ALL your queries (replaces ISP as the “watcher”)
Local network rules (DNS-based content filtering, ad-blockers running at the router level) get bypassed
Some corporate networks complain because they lose visibility for security/compliance

For ordinary use: DoH is a privacy win. For Bible Quest, no action needed — Vercel handles its DNS, users’ DNS is their own.

Common gotchas

A CNAME cannot coexist with other records at the same name. DNS rules. So a CNAME at the apex (example.com) is forbidden; you need an A record at the apex. Hosts like Vercel provide an A record for the apex; some DNS providers (Cloudflare) offer “CNAME flattening” or “ALIAS” records that work around this.
The apex domain (example.com) needs special treatment. A records, not CNAME. See above.
Propagation is cache-expiration, not pushing. Changes to DNS don’t notify caches. They wait for cache TTL to expire.
Lower TTL BEFORE changing records. A 24-hour TTL means a 24-hour propagation window. Lower to 5 minutes a day before; change; let stabilize; raise back.
Some ISPs ignore short TTLs. Comcast historically capped to 24h. Effective TTL is the longest cache in the chain.
Browser DNS cache is INDEPENDENT of OS cache. Restarting your browser clears the browser cache. Flushing OS doesn’t touch the browser’s.
Chrome has a built-in DNS cache management page: chrome://net-internals/#dns. Click “Clear host cache.”
nslookup is the simple debugging tool. nslookup stmarkbible.com 1.1.1.1 queries 1.1.1.1 directly, bypassing your default. Useful for verifying what the authoritative answer is.
dig is the powerful debugging tool. dig +trace stmarkbible.com shows the FULL resolution path from root to authoritative. Available on macOS / Linux / WSL.
Negative caching. Resolvers cache NXDOMAIN (does-not-exist) responses too. If you create a record after the resolver cached “doesn’t exist,” users see the NXDOMAIN until that negative cache expires. SOA’s minimum field governs negative TTL.
www and apex are independent. Setting example.com doesn’t set www.example.com. You typically handle both with separate records.
* wildcard records match anything not explicitly defined. * IN A 76.76.21.21 matches ALL subdomains. Useful for SaaS apps with per-tenant subdomains; surprising if forgotten.
TXT records can hold ANY text. Used for SPF (sender policy), DKIM (mail signing), DMARC (mail policy), domain verification, etc. Multiple TXT records per name are allowed.
Email DNS (MX, SPF, DKIM, DMARC) is its own rabbit hole. Misconfigured = email goes to spam or fails to deliver. Tools like mxtoolbox.com verify.
DNS records aren’t case-sensitive. STMARKBIBLE.COM and stmarkbible.com resolve identically.
The DNS protocol is mostly UDP (port 53). Some queries (large responses, zone transfers) fall back to TCP/53. Firewalls must allow both.
Some firewalls block outbound port 53. Often only allow it to specific resolvers. Affects mobile networks especially. DoH (port 443) sidesteps.
DNS-based load balancing returns multiple IPs for one name. Clients pick one (often round-robin). Some DNS providers do GeoDNS — return different IPs based on the resolver’s location.
DNS poisoning attacks insert false records into resolver caches. DNSSEC prevents most. DoT/DoH prevents many on-path attacks.
Recursive resolvers can be public (open) or restricted. Most are restricted (only ISP customers can use them). Public ones: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9), 208.67.222.222 (OpenDNS).
Your laptop’s resolver is set per-network interface. Different WiFi can use different DNS. Override via OS settings or per-app (browser’s DoH).
Cloudflare’s “proxied” mode hides your origin IP. A DNS lookup for a Cloudflare-proxied record returns CLOUDFLARE’S IP, not your origin’s. Saves DDoS, hides origin location. Disable for records that need direct routing (MX, some non-HTTP services).
Apex records can’t be CNAMEs but ANAME / ALIAS exist. Some DNS providers (Cloudflare, Route 53, DNSimple) offer pseudo-records that work like CNAMEs at the apex by resolving the target’s IPs on the fly. Not standard but widely supported.
DNS history can leak through CT logs (for HTTPS sites). Certificate transparency means every issued cert is publicly logged with its domain. If you have secret subdomains for staging, expect them to be findable.
A domain’s nameservers can be at a DIFFERENT provider than its registrar. You buy at Namecheap, host DNS at Cloudflare, serve content from Vercel. The chain: registrar (Namecheap) → nameservers (Cloudflare’s ns.cloudflare.com) → records (configured at Cloudflare) → A record (pointing at Vercel’s 76.76.21.21).
DNS changes require the EXACT name match. WWW.example.com vs www.example.com — they’re the same to DNS, but interfaces sometimes get confused. Always use lowercase.
Subdomain delegation. You can put records for *.dev.example.com on a DIFFERENT nameserver than the rest of example.com via NS records. Useful for letting a sub-team manage a chunk independently.
The root zone is signed (DNSSEC). Root → TLDs → some second-level. The “chain of trust” for DNSSEC starts at the root.
AI-generated DNS records may have wrong TTLs / formats. Always cross-check generated config before applying. Verify with dig.
dnschecker.org and mxtoolbox.com are the canonical online tools. Bookmark them. Use them every time you change DNS.
For Bible Quest specifically: Vercel hosts the DNS for stmarkbible.com. Records are managed at vercel.com/account/domains. Changes propagate from Vercel’s nameservers to caches worldwide — usually 5-30 minutes for most users; up to a couple hours for slow caches.

Modern variants worth knowing

A few extensions / alternatives:

mDNS (multicast DNS) — used by Apple Bonjour, ChromeCast discovery. Works on LANs only (.local TLD). Not relevant for webapp dev.
DNS-SD (DNS Service Discovery) — protocol on top of DNS for advertising/finding services.
DoQ (DNS over QUIC) — newer than DoH, uses QUIC’s transport. Niche but rising.
DNS-over-TOR / DNS-over-VPN — sends DNS through privacy-focused intermediaries.
ECH (Encrypted Client Hello) — encrypts the SNI in TLS handshakes; combined with DoH, hides domain name from observers entirely. Rolling out in 2024-2026.

Sources

RFC 1034 — DNS concepts (1987, still authoritative)
RFC 1035 — DNS implementation
RFC 6891 — EDNS0
RFC 7858 — DNS over TLS (DoT)
RFC 8484 — DNS over HTTPS (DoH)
Cloudflare Learning — How DNS works
DNS for Cats (free book) — friendly modern intro
dnschecker.org — live propagation across regions
mxtoolbox.com — DNS + email record validation
Verisign root server tech

Tech & AI, Explained

Explorer

dns-deep-dive