IT · Security · Tech Commentary
How DNS Works
← Learn
From typing a URL to getting an IP — recursive resolvers, authoritative servers, caching, and why DNS is almost always the answer when something breaks.
Step 01
You type a URL
Browser

You type example.com into your browser. The browser extracts the hostname and needs to resolve it to an IP address before it can open a TCP connection. Everything starts here.

Step 02
Browser cache check
Browser

The browser first checks its own internal DNS cache. If it has a recent, non-expired record from a previous visit, it uses it immediately — no network request needed. The TTL (Time To Live) value on the record determines how long the browser keeps it. Chrome: chrome://net-internals/#dns to inspect the cache.

Step 03
OS cache and hosts file
Operating System

No cached record in the browser? The OS resolver takes over. It checks the local hosts file first (/etc/hosts on Linux/macOS, C:\Windows\System32\drivers\etc\hosts on Windows) — entries here always win. Then it checks the OS DNS cache. If found, done. The system returns the result to the browser without a network query.

Step 04
Query the recursive resolver
Recursive Resolver

Still no answer. The OS sends a UDP query on port 53 to a recursive resolver — usually your ISP's DNS server, or a public resolver like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google). This resolver does the heavy lifting on your behalf. It also has its own cache — if another client recently asked the same question, you get an instant answer here.

Step 05
Resolver asks a root nameserver
Root Nameserver

Cache miss on the resolver. It contacts one of 13 root nameserver clusters (operated by ICANN, VeriSign, Cogent, and others). There are actually hundreds of physical servers behind those 13 IP addresses using anycast routing. The root doesn't know the answer — but it knows who handles .com (or .org, .net, etc.). It responds with a referral: "Go ask the .com TLD nameservers."

Step 06
Resolver asks the TLD nameserver
TLD Nameserver

The resolver queries a .com TLD nameserver (operated by Verisign). Again, it doesn't know the final IP — but it knows which nameservers are authoritative for example.com. It responds with another referral: "The authoritative nameservers for example.com are ns1.example.com and ns2.example.com — go ask them."

Step 07
Authoritative nameserver answers
Authoritative Nameserver

The resolver queries example.com's authoritative nameserver — the server configured by whoever registered the domain with their registrar. This server holds the actual DNS records. It responds with the A record: the IP address for example.com, plus a TTL value telling the resolver how long to cache the result.

Step 08
Resolver caches and returns the answer
Resolver → OS → Browser

The resolver stores the answer in its cache for the TTL duration — so the next client asking the same question gets an instant cached response. It returns the IP to your OS, which passes it to the browser. The browser opens a TCP connection to the IP on port 80 or 443. Total time for an uncached full lookup: typically 20–120ms. For a cached response: under 1ms.

TTL — Time To Live

A record's expiry timer in seconds. Resolvers and clients cache the response for this long. Low TTL (60s) = changes propagate fast but more queries hit your nameservers. High TTL (86400s) = faster for clients but slow rollbacks. Typical: 300–3600s. During a migration, lower TTL 24–48 hours in advance.

Caching Layers

Each level caches independently — browser, OS, and resolver all have separate caches with independent TTL clocks. This is why DNS changes don't take effect instantly. Force a flush: ipconfig /flushdns (Windows), sudo dscacheutil -flushcache (macOS), or sudo systemd-resolve --flush-caches (Linux).

UDP vs TCP

DNS queries use UDP port 53 by default — fast, no handshake. TCP port 53 is used when responses exceed 512 bytes, for zone transfers (AXFR), and with DNSSEC. Unusual TCP/53 traffic warrants investigation — it may indicate DNS tunneling (data exfil hidden in DNS queries) or unauthorized zone transfers.

Type Description Example
A
Address
Maps a hostname to an IPv4 address. The most common record type — what most DNS queries ultimately resolve to.
example.com → 93.184.216.34
AAAA
IPv6 Address
Maps a hostname to an IPv6 address. Four times the length of an A record. Increasingly important as IPv4 exhaustion continues.
example.com → 2606:2800:220:1::93
CNAME
Canonical Name
An alias pointing to another hostname. The resolver follows the chain until it hits an A/AAAA record. Cannot coexist with other records on the same name at the zone apex.
www.example.com → example.com
MX
Mail Exchange
Specifies mail servers for the domain. Has a priority value — lower number = higher priority. Multiple MX records provide redundancy.
10 mail1.example.com
20 mail2.example.com
NS
Name Server
Delegates a DNS zone to a set of authoritative nameservers. These are set at the registrar and point to where your DNS records are actually hosted.
example.com → ns1.registrar.com
TXT
Text
Free-form text attached to a domain. Used for SPF (anti-spam), DKIM (email signing), DMARC policies, and domain ownership verification.
v=spf1 include:_spf.google.com ~all
PTR
Pointer
Reverse DNS — maps an IP address back to a hostname. Used by mail servers to verify sending IPs. Stored under the special in-addr.arpa zone.
34.216.184.93.in-addr.arpa → example.com
SOA
Start of Authority
Contains administrative info for the zone: primary NS, admin contact email, serial number, and refresh/retry/expire/TTL timers. Every zone has exactly one SOA record.
ns1.example.com admin.example.com 2024010101 3600 900 604800 300
SRV
Service
Specifies the host and port for a specific service. Format: priority, weight, port, target. Used by SIP (VoIP), XMPP, and Microsoft Active Directory services.
_sip._tcp 10 5 5060 sip.example.com
CAA
CA Authorization
Restricts which Certificate Authorities are permitted to issue TLS certificates for the domain. A security control — any CA not listed should refuse to issue.
0 issue "letsencrypt.org"
⚠ DNS Attack Vectors
DNS Cache Poisoning / Spoofing

An attacker injects a forged DNS response into a resolver's cache, redirecting users to malicious IPs without their knowledge. The Kaminsky attack (2008) demonstrated this at scale. DNSSEC provides cryptographic signing of records to prevent forgery.

DNS Tunneling

Data is encoded inside DNS queries and responses to exfiltrate information or communicate with C2 servers covertly. Because DNS traffic is allowed almost everywhere, it bypasses most egress filters. Tools like iodine and dnscat2 implement this. Detect with anomaly detection on query volume and subdomain length.

DNS Hijacking

An attacker compromises a domain registrar account, router DNS settings, or ISP infrastructure to redirect a domain's DNS to attacker-controlled nameservers. All traffic can be silently intercepted. Enable 2FA on registrar accounts and use registrar lock features.

DNSSEC

DNS Security Extensions add cryptographic signatures to DNS records. Each record is signed with a private key, and resolvers verify the signature chain back to the root. Prevents spoofing and cache poisoning. Widely supported but not universally deployed — check with dig example.com +dnssec.

DNS over HTTPS (DoH) / DNS over TLS (DoT)

Encrypts DNS queries so ISPs and network observers cannot see which domains you're resolving. DoH (port 443) is built into browsers. DoT (port 853) is a dedicated protocol. Both prevent passive surveillance but move trust to the resolver provider instead of the local network.