You type a URL. Six servers later, a packet shows up. Walk the entire resolution chain — and finally understand why "it's always DNS."
DNS — the Domain Name System — is the reason you can type thedaddyproject.org instead of 104.21.44.197. It's the phonebook of the internet. Every single web request, email, app update, and API call starts with a DNS lookup. And yet most people, including most developers, couldn't explain exactly how it works if you asked them.
We're going to fix that. By the end of this you'll understand the full resolution chain, know the difference between every record type that matters, and understand why "it's always DNS" is a running joke among sysadmins — because it really is, constantly, DNS.
Computers route traffic using IP addresses — numbers. Humans remember names. DNS is the translation layer between the two. Without it, the internet would require everyone to memorize numerical addresses for every site they visit. With it, a human-readable name maps to the server address automatically, invisibly, in milliseconds.
But here's what makes DNS interesting: it's a distributed, hierarchical, cached system. There's no single DNS database. The responsibility for knowing which IP goes with which name is split across thousands of servers, organized in a tree structure, and the results are cached at multiple levels to keep it fast.
DNS is organized like an inverted tree. At the top is the root (represented by a dot you never type). Below that are Top-Level Domains (TLDs): .com, .org, .net, country codes like .uk and .jp. Below TLDs are second-level domains like thedaddyproject. Below those are subdomains like www or mail.
When you read a domain name left to right, you're reading from most-specific to least-specific. When DNS resolves it, it works right to left: root → TLD → domain → subdomain.
Here's what happens, in full, the first time your browser encounters a hostname it hasn't seen before:
/etc/hosts (or the Windows hosts file) for manual overrides. Still microseconds.1.1.1.1 (Cloudflare) or 8.8.8.8 (Google). This resolver does the heavy lifting. It's called "recursive" because it will make multiple queries on your behalf until it has the answer..org?" There are 13 root nameserver clusters (labeled A through M), operated by different organizations, distributed globally via anycast. They respond with the address of the .org TLD nameservers..org TLD nameserver: "Who handles thedaddyproject.org?" It responds with the address of the domain's authoritative nameservers — the ones you configured when you registered the domain.thedaddyproject.org?" This server has the actual answer — the A record (or AAAA for IPv6). It returns the IP and a TTL (time-to-live) value specifying how long to cache the result.A full uncached resolution typically takes 20–120ms. A cached answer from your local resolver: under 5ms. Your browser often has hundreds of DNS results cached at once. You almost never pay the full resolution cost in normal browsing.
| Record | Full Name | What It Does | Example |
|---|---|---|---|
| A | Address | Maps a hostname to an IPv4 address. The most common record. | thedaddyproject.org → 104.21.44.197 |
| AAAA | IPv6 Address | Maps a hostname to an IPv6 address. | example.com → 2606:4700::6810:2cc5 |
| CNAME | Canonical Name | Alias — points one hostname to another. The resolver follows the chain. | www → thedaddyproject.org |
| MX | Mail Exchanger | Specifies the mail server(s) for a domain. Has a priority number — lower = higher priority. | 10 mail.protonmail.ch |
| TXT | Text | Arbitrary text. Used for SPF, DKIM, DMARC (email auth), domain verification, and more. | v=spf1 include:_spf.google.com ~all |
| NS | Nameserver | Delegates a domain to specific authoritative nameservers. Critical for domain registration. | ns1.cloudflare.com |
| SOA | Start of Authority | Metadata for the zone: primary nameserver, admin email, serial number, refresh/retry/expire timers. | (zone housekeeping) |
| PTR | Pointer | Reverse DNS — maps an IP address back to a hostname. Used by email servers to verify senders. | 197.44.21.104.in-addr.arpa → mail.example.com |
| SRV | Service | Specifies the host and port for a specific service. Used by SIP, XMPP, some game servers. | _sip._tcp.example.com → sip.example.com:5060 |
| CAA | Certification Authority Authorization | Restricts which certificate authorities can issue certs for your domain. Good security hygiene. | 0 issue "letsencrypt.org" |
Every DNS record has a TTL — Time To Live — measured in seconds. It tells resolvers how long to cache the answer before asking again. Common values:
| TTL | Value | When to Use |
|---|---|---|
| 300 | 5 minutes | Before a planned migration — lets you move fast if something breaks |
| 3600 | 1 hour | Normal operations, moderate change frequency |
| 86400 | 24 hours | Stable records that rarely change (MX, NS) |
If your TTL is 86400 and you change your A record, it can take up to 24 hours for the change to propagate globally — some resolvers will serve the old IP until their cache expires. Best practice: lower your TTL to 300 at least an hour before any planned DNS change. Make the change. Wait for confirmation. Then raise the TTL back.
| Resolver | Provider | Privacy | Speed |
|---|---|---|---|
| 1.1.1.1 / 1.0.0.1 | Cloudflare | Strong — no query logging by policy, audited | Fastest globally |
| 8.8.8.8 / 8.8.4.4 | Used to improve Google services | Very fast | |
| 9.9.9.9 | Quad9 | No PII logging, blocks malicious domains | Fast, security-focused |
| ISP default | Your ISP | Often logs and may sell query data | Variable |
Traditional DNS queries are sent in plaintext over UDP port 53. Anyone on your network — your ISP, a coffee shop router, a man-in-the-middle — can see every domain you query. The scope of what that exposes is larger than most people realize. Security researcher Paul Ducklin put it plainly on Security Now! #723: "If I unlawfully sniff your DNS traffic so I know where you went, I'm violating your privacy. Merely by knowing where you surfed, without getting any details of what you actually surfed, I can infer an awful lot about you. I can probably piece together your daily routine, both at work and at home; figure out your likes and fears; learn which companies you do business with, which bank you use, the shops you frequent, the clubs you belong to, the hobbies you enjoy, the medical surgery you're registered with, the sports teams you support, and much more."
DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt the query so observers can't see what you're resolving.
DoH/DoT encrypts the DNS query — but the IP address you connect to afterward is still visible. And TLS's SNI field (the hostname you're connecting to) is visible in the handshake unless Encrypted Client Hello (ECH) is in use. Full traffic privacy requires a VPN or Tor. DNS encryption is a meaningful improvement, not a complete solution.
DNS was designed without authentication — a malicious server could lie about IP addresses and your resolver would have no way to know. DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. Your resolver can verify the signature chain from the root all the way down to the authoritative nameserver, confirming the answer hasn't been tampered with.
DNSSEC doesn't encrypt queries (that's DoH/DoT's job) — it authenticates them. Steve Gibson's precise framing from Security Now! #723: "DNSSEC is not encryption. It provides cryptographically signed DNS records. It was never intended to provide privacy, only authenticity. The records are signed and cannot be tampered with — but anyone watching the traffic will still see the DNS client's queries and their replies just as if DNSSEC was not in use." It's widely deployed on TLD zones (.gov, .org) but adoption at the domain level is still patchy. Worth enabling on any domain you manage.
| Symptom | Likely Cause | How to Debug |
|---|---|---|
| Site works on mobile data but not home Wi-Fi | Your home router's DNS cache has a stale entry, or the ISP resolver is returning the wrong answer | nslookup domain.com 1.1.1.1 — compare to nslookup domain.com |
| "Server not found" immediately after changing DNS records | Old TTL hasn't expired yet — resolvers are still caching the previous answer | Wait for old TTL. Use dig +trace to bypass cache and query authoritative servers directly. |
| Email bouncing / "domain doesn't exist" | Missing or misconfigured MX record; PTR record mismatch on sending server | dig MX domain.com && dig -x [mail server IP] |
| CNAME loop | A CNAME points to another CNAME that eventually points back to itself | dig +trace will show the loop |
| Works globally but broken for one person / region | Anycast routing serving different authoritative answers by region; or local ISP resolver issue | Use a tool like dnschecker.org to query from multiple global locations |
# Basic lookup
dig thedaddyproject.org
# Specific record type
dig MX gmail.com
dig TXT thedaddyproject.org
dig AAAA cloudflare.com
# Bypass your local cache — query a specific resolver
dig @1.1.1.1 thedaddyproject.org
# Trace the full resolution chain from root to authoritative
dig +trace thedaddyproject.org
# Reverse lookup (IP to hostname)
dig -x 104.21.44.197
# Old-school but still works
nslookup thedaddyproject.org
nslookup -type=MX gmail.com
When DNS seems broken: 1) Check with dig @1.1.1.1 to bypass local cache. 2) Check with dig +trace to walk the full chain. 3) Check TTL values — is this a propagation delay? 4) Check the authoritative nameservers directly. 90% of DNS mysteries are TTL cache issues or a typo in a record.
1.1.1.1 (Cloudflare), 8.8.8.8 (Google), 9.9.9.9 (Quad9)dig +trace is your best friend