How DNS works: resolution, records and why it's sometimes slow

Every time you load a website something invisible and remarkable happens first: your device asks a globally distributed hierarchy for that domain's IP, and gets an answer in milliseconds. That system — DNS — is the internet's phone book, and understanding it explains everything from why a domain "hasn't propagated" to how attackers can hijack your email.

Full resolution: the journey of one query

You type miguelacm.es and the browser needs an IP. What happens behind the scenes:

1. Local caches: browser first, then operating system. If they know the answer and it hasn't expired (TTL), done.
2. Recursive resolver: if nobody has it, the query travels to the configured resolver — your router's or a public one like 1.1.1.1 or 8.8.8.8. This one does the heavy lifting and keeps its own cache shared among users.
3. Root servers: if it still doesn't have it, ask one of the 13 root server groups (a.root-servers.net...m.). They don't know where miguelacm.es is, but they know who manages .es: they answer with the addresses of that TLD's name servers.
4. TLD servers (Verisign/red.es for .es): still not the final IP, but they do know the domain's authoritative nameservers — wherever its DNS zone lives.
5. Authoritative nameserver: the single source of truth. It answers with the definitive record, which travels back up the chain getting cached at each level per its TTL.

This whole trip typically takes 10-100 ms thanks to 90% of queries never passing step 1 or 2.

The records that matter

A DNS zone is a typed table:

Nuances that prevent real mistakes:

• A CNAME cannot coexist with other records on the same name. That's why the apex (mydomain.com) usually uses A/ALIAS/ANAME while subdomains use CNAMEs freely.
• MX and CNAME don't mix either: a domain receiving email needs direct MX records, no aliases in between.
• TXT records do far more work than they appear to: SPF declares which servers may send email as your domain, DKIM publishes message-signing keys, and ACME uses TXT records to validate domains when issuing wildcard certificates.

TTL: the parameter governing changes

Every record carries a TTL (time to live) in seconds: how long any intermediate cache may keep it. TTL 3600 = up to one hour of residual propagation after a change.

The professional strategy for server migrations: lower the TTL to 60 seconds 24 hours before the change, migrate, verify, then raise the TTL back to normal (3600-86400). The change propagates fast when you make it; afterwards long caches save traffic and queries.

"My DNS hasn't propagated" almost always means: your local resolver still caches the old value within its TTL. There's no planetary magic propagation — there are independent caches expiring at different rates.

When DNS fails or lies

Typical failures have direct diagnoses:

• NXDOMAIN (domain doesn't exist): missing record, typo, or expired registration. Check whois.
• SERVFAIL: authoritative nameserver is down or answering badly. The domain exists but nobody answers correctly.
• Slow answers: saturated resolver or long chain; trying a different public resolver confirms it.
• Stale records despite changing them: local cache (ipconfig /flushdns), public resolver cache, or simply a live TTL.

And the serious threats:

• DNS spoofing/cache poisoning: an attacker gets a resolver to cache a fake IP for your domain. Mitigation: DNSSEC, which cryptographically signs records enabling validation from the root.
• Email hijacking via lax SPF: if your SPF TXT says +all or doesn't exist, anyone can send email pretending to be your domain. The SPF + DKIM + DMARC trio closes this hole.
• Subdomain takeover: a CNAME points at a service you stopped using; whoever claims that external service controls the subdomain. Audit orphaned records periodically — our subdomain finder via Certificate Transparency helps discover what you have published and forgotten.

Debug like a pro with dig

The universal tool (built into Linux/macOS, available on Windows via WSL or nslookup):

# Direct query against default resolver
dig miguelacm.es

# Ask ONE specific nameserver (bypasses caches)
dig @ns1.vercel-dns.com miguelacm.es

# Other record types
dig miguelacm.es MX
dig miguelacm.es TXT +short

# Show the full delegation path
dig +trace miguelacm.es

+trace is gold for diagnostics: it replicates the real query step by step (root → TLD → authoritative) and shows exactly which link breaks a delegation.

Check your own records

Our online DNS lookup runs these queries from your browser and presents every record type for any domain in readable form — the fast way to review a zone without opening a terminal.

FAQ

Which public resolver should I use? For privacy and speed, 1.1.1.1 (Cloudflare) or 9.9.9.9 (Quad9, filters malware). Latency differences between major resolvers are minimal in practice; logging policy and filtering matter more.

Does changing nameservers affect my website? Only if the new nameservers lack the same zone. Before moving nameservers, replicate ALL records into the new zone and verify with dig against them.

Why does my subdomain work on mobile but not on office WiFi? Corporate networks with their own resolvers filtering or aggressively caching. Compare answers between your local resolver and a public one to confirm.

Look up any domain's DNS records with our DNS Lookup tool, free and right in your browser.