DevEvery connection you make starts with a question: what IP address is this name? DNS — the Domain Name System — is the distributed database that answers it. It is also the reason “the site is down” so often means “the site is fine; its name is broken”. This guide follows one lookup step by step, catalogues the record types you’ll actually encounter, and explains the behaviours (caching, TTL, “propagation”) that puzzle everyone the first time they change a record.
The lookup, step by step
You type devclamp.com into a browser. Before any HTTP happens:
- Local caches answer if they can. The browser, then the operating system, check their caches. A hit ends the story in under a millisecond.
- The stub asks a recursive resolver. Your OS forwards the question to the resolver from your network settings — usually your ISP’s, or a public one like 1.1.1.1 or 8.8.8.8. The recursive resolver does the legwork and caches aggressively.
- The resolver asks a root server: “who handles
.com?” The root doesn’t know the answer, but knows the TLD (top-level domain) servers for.comand refers the resolver to them. - The resolver asks a
.comserver: “who handlesdevclamp.com?” Another referral — to the authoritative name servers for that domain (often your registrar’s or your DNS host’s, e.g. Cloudflare’s). - The resolver asks the authoritative server: “what is the A record for
devclamp.com?” This time it gets an answer: an IP address, plus a TTL saying how long the answer may be cached. - The answer travels back, being cached at the resolver (and then by your OS and browser), and the browser connects to the IP.
The design lesson is in the referrals: no single machine knows the whole namespace. Root servers know TLDs, TLD servers know domains, authoritative servers know their own records — a hierarchy of caches and delegations that scales to every name on Earth.
The record types you’ll actually meet
| Type | What it holds | Example |
|---|---|---|
| A | An IPv4 address | devclamp.com → 172.67.x.x |
| AAAA | An IPv6 address | The same name, 128-bit answer |
| CNAME | An alias to another name | www.example.com → example.com |
| MX | Mail servers for the domain, with priorities | calrepo.com → mail provider |
| TXT | Arbitrary text — verification tokens, SPF/DKIM policy | v=spf1 include:… ~all |
| NS | The authoritative name servers for the (sub)domain | Delegation itself, as a record |
| SOA | The zone’s administrative record (serial, refresh timers) | One per zone |
| PTR | Reverse lookup: an address back to a name | Mostly for mail-server reputation |
Two rules cause most confusion: a CNAME cannot coexist with other records at the same name (which is why CNAMEs at the bare domain — the “apex” — are special and providers implement workarounds), and MX/NS records must point to names, not IP addresses.
TTL, caching, and the myth of propagation
Every record carries a TTL (time to live, in seconds): how long resolvers may cache it. Change a record with a 24-hour TTL and some users will keep receiving the old answer for up to a day — not because anything is “propagating” across the internet, but because caches everywhere are independently counting down the promise you made yesterday. Nothing travels; things expire.
The operational consequence: before a planned change (a migration, a host switch), lower the TTL to 300 seconds a day or two in advance, make the change, verify, then raise it again. And when something looks half-broken after a change — fine for you, stale for a colleague — suspect a cache holding the old answer before you suspect the new record.
Who sees your question?
Your recursive resolver sees every name you look up, which is a meaningful privacy fact: the default resolver is your ISP’s. Public resolvers trade that for their own (published) logging policies, and DNS-over-HTTPS / DNS-over-TLS encrypt the stub-to-resolver leg so the local network can’t watch. Note the asymmetry, though: encrypting DNS hides the name you asked about; the site you then connect to is still visible via its IP — and the address you arrive from is visible to the site, which is what our What’s My IP tool displays, along with whether that address is public or a shared one.
Failures, translated
- NXDOMAIN — the name does not exist: a typo, an unpublished subdomain, or a record someone deleted.
- SERVFAIL — the chain broke: authoritative servers unreachable, or DNSSEC validation failing. Often a provider-side problem, occasionally an expired domain.
- The site loads for some people, not others — caching asymmetry after a change (above), or an AAAA record pointing at a dead IPv6 address while the A record is fine.
- Mail rejected or flagged — missing or stale MX/SPF/DKIM TXT records; mail is where DNS errors send invoices.
Once DNS has done its work you hold an IP address and the story hands over to routing, NAT and the rest of the network stack — the world our subnet and IP guides cover. DNS is just the phone book; but as any day with a broken record teaches, nobody connects to anything without it.