DNS Deep Dive
Resolution hierarchy, record types (A, AAAA, CNAME, MX, TXT, NS), caching and TTL, EDNS, DNSSEC, DNS-over-HTTPS, zone transfers, and how DNS underpins every web request.
Beginner14 min
DNSProtocolInfrastructure
Loading lesson…
Resolution hierarchy, record types (A, AAAA, CNAME, MX, TXT, NS), caching and TTL, EDNS, DNSSEC, DNS-over-HTTPS, zone transfers, and how DNS underpins every web request.
Before a browser can load any website, it needs to find the server's IP address. That lookup travels through a multi-layered distributed system called the Domain Name System (DNS). Understanding how DNS works - from caching to DNSSEC to zone transfers - is essential for debugging performance issues, hardening security, and managing infrastructure at scale.
Every DNS lookup starts local and works its way outward. The browser first checks its internal cache. If the address is not there, it asks the operating system, which maintains its own DNS cache from previous lookups. On a cache miss, the OS sends a query to a recursive resolver - typically operated by your ISP, a public provider like Cloudflare (1.1.1.1) or Google (8.8.8.8), or a corporate network.
The resolver then walks the DNS hierarchy from the root. It starts at one of the 13 root nameservers, which respond with a referral to the appropriate TLD (Top-Level Domain) nameserver (for example, the .com TLD server). The TLD server then refers the resolver to the domain's authoritative nameserver, which holds the actual records. Each step is a referral, not the answer - only the authoritative server gives the final response.
Resolution path for www.example.com:
1. Browser cache -> miss
2. OS cache -> miss
3. Recursive resolver -> query root (.) server
4. Root server -> refer to .com TLD
5. .com TLD server -> refer to example.com nameservers
6. Authoritative -> a.iana-servers.net
nameserver returns A record: 93.184.216.34
7. Response returned -> resolver caches, passes to OS, passes to browserRecord types tell the resolver what kind of data is being requested. A records map a hostname to an IPv4 address. AAAA maps to IPv6. CNAME creates an alias (canonical name) that points one name to another - commonly used for www to apex redirects and CDN integrations. MX records specify mail exchange servers with priority values. TXT records hold arbitrary text, used extensively for domain verification, SPF, DKIM, and DMARC. NS records delegate subdomains to other nameservers.
TTL values control how long a response can be cached. High TTLs (86400 seconds, 24 hours) reduce resolver load and speed up repeat lookups, but make changes slow to propagate. Low TTLs (60-300 seconds) let you shift traffic quickly during migrations or failovers, at the cost of more queries against your authoritative servers. EDNS (Extension Mechanisms for DNS) extends the DNS protocol with support for larger UDP payloads, DNSSEC signalling, and client subnet information.
DNSSEC adds cryptographic signatures to DNS records so resolvers can verify authenticity. Without DNSSEC, a man-in-the-middle can forge DNS responses and redirect users to malicious servers (cache poisoning). With DNSSEC, each zone signs its records with a private key, and resolvers validate the signature chain from the root zone down. Adoption has grown steadily, but many domains still lack DNSSEC protection.
DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt DNS queries so that observers on the network cannot see what domains you are resolving. DoH sends DNS queries inside HTTPS requests on port 443, making them indistinguishable from regular web traffic. DoT uses a dedicated TLS connection on port 853. Both prevent eavesdropping and tampering, though they shift trust from your ISP to the DoH/DoT provider.
Zone transfers allow secondary nameservers to replicate zone data from a primary server. An AXFR (full zone transfer) sends the entire zone file. IXFR (incremental zone transfer) sends only changes since a serial number. Zone transfers must be restricted to authorised servers only - an open AXFR is a critical information disclosure vulnerability that exposes every record in a domain.
Type a domain below to simulate the step-by-step DNS resolution process. Choose the record type to see how different queries return different data. Watch the TTL countdown and try flushing the cache to force a fresh resolution.
Every HTTP request starts with a DNS lookup. A slow resolver adds latency to every page load before a single byte of content is fetched. Understanding the resolution path helps you diagnose "why is the site slow?" - is it resolver latency, a misconfigured TTL, or an authoritative server under load? Tools like dig, nslookup, and drill expose every step.
DNS security is a vast attack surface. DNS rebinding tricks the browser into making requests to internal IPs by rapidly cycling DNS responses. DNS tunnelling encodes data inside DNS queries to bypass network controls. Cache poisoning (the Kaminsky attack) injects forged records into a resolver's cache. DNSSEC prevents cache poisoning but does not protect against rebinding or tunnelling - those require application-layer defences.
Deployment considerations revolve around TTL management. Planning a migration? Lower the TTL to 60 seconds a few days beforehand so the new records propagate quickly when you flip. Forgot to lower TTL? You will be waiting hours for the old records to expire. CNAME flattening (ANAME/ALIAS records) lets apex domains use CNAME-like aliasing without breaking the DNS spec. SPF, DKIM, and DMARC records (all stored as TXT records) control email authentication and prevent spoofing.
Restrict zone transfers to authorised secondary nameservers only. An open AXFR query leaks your entire zone to anyone on the internet - subdomains, internal hostnames, and service records that expand the attack surface. Use TSIG (Transaction Signatures) or IP allowlists to authenticate secondary servers.
Enable DNSSEC signing on your domains. Most registrars and DNS providers offer one-click DNSSEC. The overhead is minimal and the protection against cache poisoning is complete. For user-facing applications, consider deploying DNS-over-HTTPS resolvers (such as Cloudflare 1.1.1.1 or Google 8.8.8.8) to protect query privacy and integrity.
Validate SPF, DKIM, and DMARC configurations for your domains to prevent email spoofing. Use a strict DMARC policy (p=reject) once you have confirmed legitimate mail flows correctly. Monitor DNS query logs for unusual patterns that might indicate data exfiltration via DNS tunnelling.
1.What happens when a DNS resolver receives a response with a TTL of 60 seconds?
2.Which DNS record type is used to verify domain ownership for email authentication (SPF)?
3.What is the primary security benefit of DNSSEC?