DNS
The Domain Name System: the world's largest distributed database, resolving 3.5 trillion queries per day — and the infrastructure that can redirect or bring down the entire internet when misconfigured.
// Chapter 1
The Phone Book That Runs the Internet
Story
1983. The internet has grown from a handful of ARPANET nodes to hundreds of machines. Every computer keeps a local HOSTS.TXT file, downloaded from a central server at Stanford Research Institute. It maps hostnames to IP addresses. You add a new machine — you submit a request to SRI, wait for the next update, and hope every other machine downloads it. With hundreds of machines this was manageable. By the time the internet had thousands of machines, it was impossible. Elizabeth Feinler's team at SRI was drowning in update requests.
Paul Mockapetris invented the Domain Name System in 1983 (RFC 882, 883). Instead of one central file, DNS is a distributed, hierarchical, delegated database. No single machine knows all the answers. Queries are routed to whoever is authoritative for each piece of the namespace. Every organization manages its own zone. The same protocol scales to 3.5 trillion queries daily serving 3.5 billion internet users — from the same design invented 40 years ago.
DNS translates human-readable names (www.example.com) into machine-routable numbers (93.184.216.34). But it is far more than a phone book — it is a general-purpose distributed key-value database that stores email routing, security policies, certificate restrictions, service discovery, and cryptographic keys.
Wow
DNS handles approximately 3.5 trillion queries per day globally. Cloudflare's 1.1.1.1 alone handles over 1 trillion daily. Every web page load triggers 10–40 DNS queries. DNS failure is catastrophic: in 2021, a Fastly CDN misconfiguration took down Reddit, GitHub, Hacker News, the BBC, and hundreds of other sites simultaneously — not because of a routing failure, but because their DNS records pointed to Fastly infrastructure that suddenly became unreachable. DNS is the single point of failure for the entire internet.
// Chapter 2
The Hierarchy: Dots, Zones, and Delegation
Domain names are read right-to-left. In www.example.com., the trailing dot is the root zone (usually omitted but always implied). com is a Top-Level Domain. example is a second-level domain registered under .com. www is a hostname within example.com's zone. Each dot represents a delegation boundary — a handoff from one authority to another.
Zones vs Domains
A zone is an administrative unit of delegation. The example.com zone contains all records that example.com's administrators control. They could delegate blog.example.com to a different team or hosting provider, creating a new zone with its own NS records and authoritative servers. The parent zone stores only the delegation (NS records pointing to blog's servers and glue A records). A domain is the full namespace subtree — example.com includes all sub-zones, whereas the example.com zone is just what hasn't been delegated away.
Root Zone, TLDs, and IANA
The root zone contains ~1,500 entries — one NS delegation per TLD. Root zone data is managed by IANA and published to 13 root server addresses (a–m.root-servers.net). These 13 logical addresses are served by over 1,600 physical anycast instances in 130+ countries. Your resolver bootstraps the entire chain from a hardcoded "root hints" file listing these 13 addresses.
ICANN delegates TLDs to registry operators: Verisign operates .com and .net, Public Interest Registry operates .org, and country code TLDs (.uk, .de, .jp) are delegated to national registries. New Generic TLDs (.app, .dev, .io, .ai) were allocated through ICANN's gTLD program starting in 2012.
// Chapter 3
DNS Resolution: The Full Walk
Story
When you type www.example.com and press Enter, your browser doesn't know the IP address. Your OS doesn't know. Your home router doesn't know. But through a chain of referrals — root to TLD to authoritative server — the answer is found within milliseconds. And once found, it is cached so the next person asking pays nothing. This distributed cache structure is why DNS handles trillions of queries per day without breaking.
DNS Resolution Walkthrough — click any step
Recursive vs Iterative Queries
Your computer sends a recursive query (RD=1 bit set): "please find this for me." The recursive resolver does all the work. When the recursive resolver queries root and TLD servers, it uses iterative queries: "what can you tell me?" and follows referrals step by step. The resolver caches every intermediate result — NS records, glue records, final A records — to avoid repeating the walk for subsequent queries.
Negative Caching
NXDOMAIN (Non-Existent Domain) responses are also cached — for the duration of the SOA MINIMUM field (RFC 2308). Without negative caching, every query for a nonexistent name would traverse the full resolution chain on every attempt. The negative TTL is typically much shorter than positive TTL — 300s is common — to allow recently-created domains to become reachable quickly.
# Manual DNS resolution trace dig +trace www.example.com # shows every referral step, root to auth dig @8.8.8.8 A www.example.com # query Google recursive resolver dig @a.root-servers.net A www.example.com # iterative query to root # Clean answer with TTL dig +nocmd +noall +answer www.example.com # Reverse DNS dig -x 93.184.216.34 # Check from multiple resolvers for r in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do echo -n "$r: "; dig +short @"$r" A www.example.com done
// Chapter 4
DNS Record Types
DNS records are the data stored in zones. Each record has a name, class (always IN for internet), type, TTL, and RDATA (record-specific data). Records with the same name and type form an RRset (Resource Record Set) — always cached and returned together. Understanding record types is essential for configuring everything from web hosting to email security to TLS certificate management.
DNS Record Type Explorer
A Record
Maps a hostname to an IPv4 address. The most fundamental record — the final answer in most DNS lookups.
Example
www.example.com. 3600 IN A 93.184.216.34
TTL Note
TTL 300–3600s typical. Low for fast failover; high for cache efficiency.
Use Case
Web servers, API endpoints, any IPv4-addressed service
The CNAME Restriction
RFC 1912 prohibits a CNAME at a name that has any other records. This creates a critical operational constraint: you cannot put a CNAME at a zone apex (example.com itself) because zone apexes require NS and SOA records. This is why CDN providers offer proprietary "ALIAS" or "ANAME" records — they behave like CNAME but are stored as A records internally, resolving at the server side, allowing apex usage. Route53 calls these "Alias records"; Cloudflare calls it a "CNAME flattening."
Caution
CNAME chains multiply latency: a chain A → B → C → D requires four DNS lookups before returning an IP. RFC 1034 says resolvers should follow at most 8 CNAMEs before giving up. Circular CNAMEs (A → B → A) cause resolution failures. Keep chains short — one CNAME hop is usually enough. Each CDN or alias layer you add is another round trip.
// Chapter 5
TTL: The Cache Management Knob
TTL (Time-to-Live) is the number of seconds a resolver may cache a DNS record. It is the most important operational parameter in DNS — getting it wrong causes either stale data (TTL too high) or excessive DNS query load and latency (TTL too low).
TTL Strategy by Record Type
• Static content, CDN endpoints: 3600–86400s. These rarely change; high TTL improves global cache hit rates.
• Services that might failover: 60–300s. Low enough that failover changes propagate within minutes.
• MX, NS records: 3600–86400s. Rarely change; high TTL reduces unnecessary queries to authoritative servers.
• Planned maintenance: lower TTL to 60–300s at least 24 hours before the change (to let all caches pick up the short TTL), make the change, then raise TTL back. Never lower TTL immediately before a change — existing caches may already hold a 24-hour TTL copy.
Wow
Cloudflare's 1.1.1.1 claims to be the world's fastest public DNS resolver at ~11ms average response time globally. Google's 8.8.8.8 averages ~20ms. Both use anycast routing to 200+ PoPs worldwide. Quad9 (9.9.9.9) focuses on security — it blocks malicious domains by default using threat intelligence feeds. OpenDNS (208.67.222.222) has offered content filtering since 2007. All four are free, high-availability, privacy-varying alternatives to ISP resolvers.
// Chapter 6
Authoritative Servers and Zone Files
Authoritative name servers hold the definitive data for a zone and respond with the AA (Authoritative Answer) flag set. When you register example.com and configure it to use Cloudflare DNS, Cloudflare's servers become authoritative for your zone — they are the source of truth.
Zone File Format (RFC 1035)
DNS zone data is stored in master file format. The $ORIGIN directive sets the default domain suffix. The @ symbol refers to the current origin. The SOA record is mandatory first — it defines zone metadata including the serial number that triggers secondary synchronization.
; example.com zone file (RFC 1035 master format)
$ORIGIN example.com.
$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
2024012001 ; Serial — YYYYMMDDNN, must increment on every change
3600 ; Refresh — seconds between secondary polls
900 ; Retry — if refresh fails
604800 ; Expire — secondary stops serving after 7 days
300 ) ; Negative cache TTL (NXDOMAIN)
; Name servers
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
; A records
@ IN A 93.184.216.34
www IN A 93.184.216.34
api IN A 93.184.216.100
; AAAA
@ IN AAAA 2606:2800:220:1:248:1893:25c8:1946
; Email
@ IN MX 10 mail.example.com.
@ IN TXT "v=spf1 ip4:93.184.216.50 ~all"
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
; Certificate authority restriction
@ IN CAA 0 issue "letsencrypt.org"Zone Transfers: AXFR and IXFR
Secondary servers replicate zone data from the primary via zone transfers. AXFR (full transfer): the secondary requests the complete zone whenever the SOA serial is higher than its own copy. IXFR (incremental): only changed records are transferred — efficient for large zones with frequent small updates. Modern DNS hosting (Route53, Cloudflare DNS) abstracts all of this — all servers share the same backend, with no traditional primary/secondary relationship.
Caution
Unrestricted AXFR (zone transfer) exposes your entire zone — every hostname, IP, and record — to anyone who asks. Always restrict AXFR to known secondary server IPs with allow-transfer { IP; }; in BIND. Information exposed via AXFR has been used in reconnaissance before targeted attacks. Many registrars and DNS providers disable AXFR entirely for security.
// Chapter 7
DNSSEC: Signing the Internet's Phone Book
Story
2008. Security researcher Dan Kaminsky discovers a critical vulnerability in DNS: cache poisoning can be performed with only 65,536 guesses — trivially achievable. The attack floods a recursive resolver with forged responses faster than the real response arrives, tricking it into caching a malicious IP for a legitimate domain. Kaminsky secretly coordinated with DNS vendors for a simultaneous patch. When the vulnerability was disclosed, every major recursive resolver in the world was patched simultaneously — the largest coordinated security response in internet history. The fix (source port randomization) increased the attack complexity to ~4 billion guesses — but DNSSEC was the real solution.
DNSSEC Chain of Trust — click a level
Root Zone (.)
Trust Anchor DNSKEY — hardcoded in every validating res…
.com TLD Zone
DS record for example.com — hash of example.com KSK
example.com Zone
DNSKEY (KSK + ZSK), RRSIG over every RRset, NSEC3 recor…
www.example.com
A 93.184.216.34 + RRSIG(A) signed by ZSK
Root Zone (.)
Record: Trust Anchor DNSKEY — hardcoded in every validating resolver
Signs: .com KSK via DS record
The root KSK was rolled for the first time in October 2018 — a coordinated global event. Misconfigured resolvers that failed to update would have lost DNS resolution for the entire internet.
How DNSSEC Verification Works
Every RRset in a DNSSEC-signed zone has a corresponding RRSIG record — a digital signature. The signature is made by the ZSK (Zone Signing Key). The ZSK public key is in a DNSKEY record, signed by the KSK (Key Signing Key). The KSK is validated via a DS record in the parent zone (the hash of the KSK), which is signed by the parent's ZSK, walking the chain up to the root trust anchor hardcoded in every validating resolver. A validating resolver checks every signature in this chain — any invalid signature triggers SERVFAIL.
NSEC3: Authenticated Denial Without Zone Walking
DNSSEC must also prove a name does not exist. NSEC records create a signed ordered chain through all zone names — but enable "zone walking": an attacker can enumerate all hostnames in a zone by following NSEC links. NSEC3 hashes the names before creating the chain, making enumeration computationally expensive. RFC 9276 (2022) recommends NSEC3 with zero iterations to prevent offline dictionary attacks against the hashes.
# Check DNSSEC signatures dig +dnssec A www.example.com # request RRSIG in response dig +dnssec DNSKEY example.com # fetch public signing keys dig +dnssec DS example.com @a.gtld-servers.net # parent DS record # Full DNSSEC validation (delv does the chain verification) delv @1.1.1.1 A www.example.com # Check DNSSEC status online # https://dnssec-analyzer.verisignlabs.com/example.com # https://www.dnssec-debugger.verisignlabs.com
// Chapter 8
DNS over HTTPS and DNS over TLS
Traditional DNS sends queries in plaintext over UDP port 53. Any observer on the network path — your ISP, a coffee shop operator, a government monitor — can see every domain you query. Your DNS queries reveal which services you use, when, and can infer sensitive personal information.
DNS over TLS (DoT) — RFC 7858
DoT wraps DNS in a TLS tunnel over TCP port 853. The DNS wire format is unchanged — only the transport is encrypted. Clean conceptual separation, easy to deploy on Android (Private DNS setting) and Linux (systemd-resolved). Disadvantage: port 853 is visible and easy to detect or block in corporate firewalls and national filtering systems.
DNS over HTTPS (DoH) — RFC 8484
DoH carries DNS queries as HTTPS POST or GET requests over port 443. Traffic is completely indistinguishable from normal web browsing. Firefox and Chrome have built-in DoH support. Advantage: cannot be selectively blocked without blocking all HTTPS. Disadvantage: centralizes DNS into a few large providers (Cloudflare 1.1.1.1, Google 8.8.8.8), bypasses corporate DNS filtering policies and local network controls.
Wow
DoH caused a major enterprise security controversy. Corporate IT uses DNS filtering to block malware C2 domains, phishing sites, and policy violations. Browser-integrated DoH routes queries directly to Cloudflare or Google over port 443 — completely bypassing corporate DNS. Mozilla delayed DoH rollout after pushback from enterprise customers and UK's NCSC, which named Mozilla an "internet villain" for 2019. The privacy vs. enterprise-visibility tradeoff remains unresolved — enterprise browsers now support "canary domains" that signal DoH should be disabled on managed networks.
# Configure DoT with systemd-resolved # /etc/systemd/resolved.conf: # [Resolve] # DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net # DNSOverTLS=yes # Test DoT with kdig (from knot-dnsutils package) kdig -d @1.1.1.1 +tls A www.example.com # DoH query via curl (JSON API) curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=www.example.com&type=A' # DNS over QUIC (DoQ) — RFC 9250 # Emerging standard, each DNS query in its own QUIC stream
// Chapter 9
DNS as an Attack Vector
DNS is both a critical target and a powerful tool for attackers. The combination of ubiquitous access, UDP's lack of source verification, and the central role of DNS in all internet communication creates a rich attack surface.
DNS Cache Poisoning
Pre-Kaminsky: 16-bit transaction ID = 65,536 guesses. Post-patch: source port randomization adds ~16 bits → ~4.3 billion guesses. With DNSSEC validation enabled, cache poisoning becomes cryptographically infeasible — the forged response would fail signature verification regardless of the transaction ID match.
DNS Amplification DDoS
UDP source addresses can be spoofed. An attacker sends DNS queries with the victim's IP as source. The resolver sends its large response to the victim. Amplification factors: DNS ANY query: up to 100x. DNSKEY query: 40–75x. A single 1 Gbps botnet can generate 40–100 Gbps of attack traffic targeting a victim via DNS amplification. Mitigations: BCP38 source address validation at ISPs, DNS Response Rate Limiting (RRL), refusing ANY queries, using TCP for large responses (TC bit set).
DNS Tunneling
Data can be encoded in DNS queries: aGVsbG8gd29ybGQ=.c2.evil.com. An attacker who controls the authoritative server for evil.com receives this data — creating a covert exfiltration or C2 channel that bypasses most firewalls (DNS is almost never blocked). Tools like iodine and dnscat2 implement full bidirectional IP-over-DNS tunneling. Detection: entropy analysis of queried names, unusually long subdomain labels, high query volume to unknown domains.
BGP Hijacking of DNS Infrastructure
In 2018, attackers hijacked BGP routes to Amazon Route53's authoritative servers, intercepting DNS responses for MyEtherWallet and stealing ~$150,000 in cryptocurrency. The attack worked because DNS had no authentication — the BGP-hijacked responses were accepted as legitimate. DNSSEC validation would have detected the tampered responses. DoH/DoT with certificate pinning would have prevented the BGP interception from being effective.
// Chapter 10
DNS Load Balancing and High Availability
DNS is often the first tier of traffic management. By controlling which IP addresses are returned — and with what TTL and weighting — you implement load distribution, geographic routing, and automatic failover.
Round-Robin DNS
Multiple A records for the same name cause resolvers to return them in rotating order. Simple and stateless. Limitation: no health awareness — traffic continues to dead servers until TTL expires. Not true load balancing — resolvers cache all records and rotate; actual load depends on TTL expiration rate and how many clients share a resolver's cache.
GeoDNS and Anycast
GeoDNS returns different answers based on the resolver's geographic location (not the end user's — an important distinction for CDN accuracy). A resolver in Tokyo gets a Tokyo IP; a resolver in London gets London. Anycast takes a different approach: advertise the same IP address from multiple data centers via BGP. The network automatically routes each user to the topologically nearest instance — without any DNS intelligence required. Cloudflare's 1.1.1.1 and 8.8.8.8 both use anycast.
Health-Checked DNS Failover
Route53, Cloudflare Load Balancing, and NS1 perform continuous health checks against your endpoints. A failed health check removes the unhealthy IP from DNS responses automatically. With a 60s TTL, downtime is limited to ~60 seconds for automatic failover — no manual intervention required. RTO (Recovery Time Objective) of under 2 minutes for full datacenter failures is achievable with DNS failover alone.
// Chapter 11
DNS Email Security: SPF, DKIM, DMARC
Three email authentication mechanisms live entirely in DNS TXT records. Together they prevent email spoofing and phishing at the source — by giving receiving mail servers a way to verify that a message claiming to be from example.com was actually authorized by example.com's administrators.
SPF — Sender Policy Framework
A TXT record listing all IP addresses and mail services authorized to send email for a domain. v=spf1 include:_spf.google.com ip4:93.184.216.50 ~all: Google's servers and the listed IP may send; all others are softfail (~all) or hardfail (-all). Receiving servers check the SPF record during the SMTP connection and can reject or mark messages from unauthorized senders. SPF checks the envelope MAIL FROM address, not the From: header a user sees.
DKIM — DomainKeys Identified Mail
The sending mail server signs outgoing messages with an RSA or Ed25519 private key. The public key is published in DNS at selector._domainkey.example.com as a TXT record. Receiving servers verify the signature — proving the message was not modified in transit and that the signer controls the DNS record. DKIM signatures survive forwarding (unlike SPF, which breaks on relay). The selector allows multiple keys for key rotation without downtime.
DMARC — Domain-based Message Authentication Reporting & Conformance
DMARC ties SPF and DKIM together with a policy: what to do when both fail? p=none (monitor only), p=quarantine (send to spam folder), p=reject (refuse the message). DMARC also enables aggregate reports (rua=) — daily XML summaries from every receiving mail server showing which messages passed/failed, sent to your monitoring address. This visibility lets you tune SPF/DKIM before enforcing rejection.
# Check email DNS records dig TXT example.com +short # SPF record dig TXT _dmarc.example.com +short # DMARC policy dig TXT selector1._domainkey.example.com +short # DKIM public key # Validate with mxtoolbox # https://mxtoolbox.com/emailhealth/example.com/ # Example SPF record with common providers: # "v=spf1 include:_spf.google.com include:mailgun.org ~all" # Example DMARC with report email: # "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"
// Chapter 12
Debugging DNS: A Systematic Toolkit
DNS problems cause a disproportionate fraction of outages. Systematic diagnosis requires querying different resolvers and servers at each level of the hierarchy.
# 1. Verify authoritative servers dig NS example.com +short dig @ns1.example.com A www.example.com # bypass cache — query auth directly # 2. Check for propagation (cache expiry) for r in 8.8.8.8 1.1.1.1 9.9.9.9; do echo -n "$r: "; dig +short @"$r" A www.example.com done # 3. Trace from root to answer dig +trace www.example.com # 4. Check DNSSEC validation delv +root @8.8.8.8 A www.example.com # Look for: "fully validated" vs "validation failed" # 5. Check negative cache (NXDOMAIN TTL) dig +ttlunits A nonexistent.example.com @8.8.8.8 # SOA minimum field controls negative cache TTL # 6. Check for split-horizon (internal vs external DNS) dig @your-internal-dns A host.example.com dig @8.8.8.8 A host.example.com # 7. Find DNS TTL remaining (time until cache refresh) dig A www.example.com # TTL column decrements until refresh
// Chapter 13
Common Misconceptions
Misconception — DNS changes take 24–48 hours to propagate
There is no propagation. DNS changes are instant on authoritative servers — the new record is live the moment you save it. The delay is existing caches expiring at their TTL. If your TTL is 300 seconds, all caches expire within 5 minutes. If your TTL is 86400s and you just changed a record, some resolvers will serve the old value for up to 24 hours. Always lower TTL 24+ hours before planned changes. The "24–48 hour" figure comes from default 86400s TTLs set by many domain registrars.
Misconception — DNSSEC encrypts your DNS traffic
DNSSEC provides authentication and integrity — not confidentiality. DNS queries and responses with DNSSEC are still transmitted in plaintext UDP. Any network observer can see every domain you query. DNSSEC only proves the answers haven't been tampered with. For confidentiality, use DNS over TLS (DoT) or DNS over HTTPS (DoH). These are orthogonal — you can and should use both DNSSEC validation and DoT/DoH simultaneously.
Misconception — DNS is just for translating domains to IPs
DNS is a general-purpose distributed key-value database. It stores: email routing (MX), email security (SPF/DKIM/DMARC in TXT), certificate authority restrictions (CAA), service discovery (SRV), SSH fingerprints (SSHFP), TLS certificate associations (TLSA/DANE), and zone administration metadata (SOA, NS). Hundreds of protocols use DNS TXT records for configuration and discovery. The "phone book" analogy captures less than 20% of actual DNS usage.
Misconception — All DNS resolvers return the same answers
GeoDNS returns different IP addresses based on resolver location. A CDN-backed domain may return a Tokyo IP when queried from Japan and a London IP when queried from the UK. Split-horizon DNS (common in corporate environments) returns different answers for internal vs. external resolvers. Filtering resolvers (9.9.9.9, 1.1.1.3, OpenDNS) return NXDOMAIN for blocked domains. Resolver choice materially affects the answers you receive — this matters for debugging latency, troubleshooting connectivity, and understanding corporate DNS behavior.
Misconception — A PTR record is automatically created when you create an A record
PTR records (reverse DNS) are in a separate zone — the in-addr.arpa zone — delegated to whoever owns the IP address space, not the domain name. If your server is at 93.184.216.34, the PTR record lives in the zone managed by IANA/the ISP owning that IP block, not in example.com's zone. You must request PTR delegation from your IP space owner (your cloud provider or ISP). AWS, Google Cloud, and Azure all allow you to set reverse DNS through their respective console or API — but you must do it explicitly.
// Chapter 14
IQ Depth Check
IQ — Beginner
DNS is like a phone book for the internet — it converts website names (like google.com) into IP addresses (like 142.250.80.46) that computers use to connect. Your computer asks a DNS server, which finds the answer and sends it back. The answer is saved (cached) for a set time called TTL. Different record types serve different purposes: A records for IP addresses, MX for email, TXT for security settings. When you register a domain, you point it at name servers that host your DNS records.
IQ — Intermediate
DNS is hierarchical: root → TLD (.com) → second-level domain → hostnames. Resolution is recursive: your stub resolver asks a recursive resolver (8.8.8.8), which walks iteratively — root referral, TLD referral, authoritative answer — and caches every step. DNSSEC cryptographically signs records to prevent cache poisoning. DoT/DoH encrypt queries for privacy. "DNS propagation" is cache expiration controlled by TTL — lower TTL before planned changes. SPF, DKIM, DMARC are email security policies published as DNS TXT records. GeoDNS and health-checked failover use DNS for traffic management and automatic recovery.
IQ — Senior
DNS caches at four levels: browser (60s), OS stub (TTL-respecting), recursive resolver (shared, massive, no flush API), negative cache (SOA MINIMUM). DNSSEC uses ZSK/KSK separation: ZSK monthly rotation for regular records; KSK annual/biennial for DNSKEY signing; DS records in parent zones bridge trust. NSEC3 with 0 iterations prevents zone enumeration and offline hash attacks. Cache poisoning post-Kaminsky: ~4.3 billion guesses (16-bit TxID × 16-bit source port). DNS amplification: DNSKEY queries achieve 40–75x amplification on spoofed UDP. DNS tunneling detected by subdomain entropy analysis, query rate, and label length. CNAME cannot coexist with other record types at same name, preventing apex CNAME — workarounds: ALIAS/ANAME records via provider-specific CNAME flattening. RFC 7816 qname minimization reduces information exposure to each authoritative server by sending only the minimal necessary QNAME.
IQ — PhD
The Kaminsky attack exploits the birthday paradox: with TxID space of 65,536 and source port space of 65,536 (post-patch combined space ~4.3×10^9), an attacker sending ~1,000 forged responses/second requires ~50 days on average — vs. ~33 seconds pre-patch. DNS COOKIE (RFC 7873) provides per-server-per-client authentication tokens eliminating off-path injection without DNSSEC overhead. The DNSSEC root KSK ceremony (ICANN) uses FIPS-140-2 Level 4 Hardware Security Modules in two geographically separate facilities with publicly-livestreamed signing ceremonies and community trust representatives — the most elaborate key ceremony in internet history. NSEC3 with iterations parameter: RFC 9276 recommends 0 iterations (disabled) because each iteration only increases attacker cost by O(1) while imposing O(1) signing cost on every zone update — the asymmetry is insufficient. RFC 7816 qname minimization reduces QNAME to just the labels needed at each delegation point — root server sees only ".", .com server sees "com." — limiting the information exposure even from operators of resolvers. Open problems: DNSSEC post-quantum migration (current RSA-2048/ECDSA P-256 RRSIG sizes: 256–512 bytes; post-quantum FALCON-512 or Dilithium signatures: 1280–2420 bytes, potentially exceeding 512-byte UDP DNS limit requiring EDNS0 buffer sizes or TCP fallback for all signed responses — a significant operational change); DNSSEC key ceremony automation without sacrificing ceremony integrity; encrypted SNI (ECH) plus DoH as a complete network-level traffic analysis mitigation system.
🎯 Key Takeaways
- ✓DNS is a hierarchical, delegated, distributed database — not a simple phone book. It stores email routing, security policies, certificate restrictions, and service discovery records.
- ✓Resolution is recursive: stub resolver → recursive resolver (does all work) → iterative root/TLD/auth queries → cached answer at every step.
- ✓"DNS propagation" is cache expiration at TTL — changes on authoritative servers are instant. Lower TTL 24+ hours before planned changes.
- ✓DNSSEC provides cryptographic authentication via a chain of signatures from root trust anchor → TLD DS record → zone KSK → ZSK → RRSIG on every RRset.
- ✓DNSSEC provides authentication and integrity, NOT confidentiality. Use DNS over TLS (DoT, port 853) or DNS over HTTPS (DoH, port 443) for encrypted queries.
- ✓Cache poisoning post-Kaminsky requires ~4 billion guesses (TxID + source port randomization). DNSSEC makes it cryptographically infeasible regardless of guesses.
- ✓DNS amplification attacks exploit UDP source spoofing to reflect large responses to victims — up to 75x amplification with DNSKEY queries.
- ✓CNAME cannot coexist with other records at the same name, preventing CNAME at zone apex — CDN providers offer ALIAS/ANAME records as workarounds.
- ✓SPF, DKIM, and DMARC are email authentication mechanisms published as DNS TXT records, together preventing email spoofing and phishing.
- ✓DNS is used for load balancing (round-robin, GeoDNS, health-checked failover), DNS tunneling (covert channel via subdomain encoding), and as an attack target for BGP hijacking.
Discussion
0Have a better approach? Found something outdated? Share it — your knowledge helps everyone learning here.