How DNS Resolution Works Under the Hood
A step-by-step technical walkthrough of what happens between typing a domain name and a browser receiving an IP address.
Core Concept
DNS resolution translates a human-readable domain name into the IP address a computer needs to establish a connection, acting as the internet's directory service.
The process is distributed and hierarchical by design — no single server holds the complete map, which keeps the system resilient and scalable.
The Resolution Chain
A typical lookup passes through several distinct stages before returning an answer.
- Browser and OS-level cache check
- Recursive resolver (often the ISP or a public resolver)
- Root nameserver, pointing to the correct TLD
- TLD nameserver, pointing to the domain's authoritative server
- Authoritative nameserver, returning the actual record
Caching at Every Layer
Each layer caches results according to the record's TTL, which is why most lookups never reach the authoritative server directly.
Where Delays and Failures Happen
Slow or failed resolution usually traces back to a small set of common causes.
- Misconfigured or unreachable authoritative nameservers
- Overly long TTLs delaying propagation of changes
- Recursive resolver outages or rate limiting
Recursive vs Authoritative Resolvers
Recursive resolvers do the legwork of querying the hierarchy on a client's behalf and cache the result for future requests.
Authoritative nameservers, by contrast, hold the actual source-of-truth records for a domain and are the final stop in any resolution chain.
Two Different Jobs
Confusing a recursive resolver with an authoritative one is a common source of misdiagnosed DNS issues.
Modern Resolution Enhancements
Several protocol extensions have improved DNS resolution's speed and privacy since its original design.
- DNS over HTTPS (DoH) for encrypted queries
- DNS over TLS (DoT) as an alternative encryption path
- EDNS Client Subnet for geographically optimized answers
Real-World Implementation
Production infrastructure leans on this resolution chain constantly, often invisibly.
- CDNs using DNS to route users to the nearest edge server
- Load balancers implemented through DNS-level traffic splitting
- Failover systems that swap records when health checks fail
Understanding this chain end-to-end is the fastest way to diagnose whether a DNS problem sits with the domain's configuration, the resolver, or somewhere in between.
Common Mistakes to Avoid
A few misunderstandings about DNS resolution lead to unnecessary troubleshooting confusion.
- Assuming a DNS change should be visible instantly everywhere on the internet.
- Overlooking browser-level DNS caching when troubleshooting a resolution issue.
- Blaming the destination server for a problem that actually traces back to the resolver.
- Not distinguishing between recursive resolver issues and authoritative nameserver issues.
- Failing to test resolution from multiple resolvers when diagnosing inconsistent behavior.
- Overlooking negative caching, which can keep an NXDOMAIN result cached longer than expected.
- Assuming all recursive resolvers behave identically in how they cache and retry.
- Failing to check whether a public DNS resolver is being used versus an ISP default.
- Overlooking DNS over QUIC as an emerging resolution transport worth tracking.
- Assuming all recursive resolvers implement DNSSEC validation by default.
- Failing to check for split-horizon DNS when internal and external results differ.
- Overlooking that some corporate networks intercept and modify DNS responses internally.
Best Practices Checklist
These practices make DNS troubleshooting significantly faster and more accurate.
- Query multiple public resolvers directly to bypass local caching during diagnosis.
- Check TTL values before assuming a change should already be visible.
- Separate recursive resolver issues from authoritative nameserver issues early in diagnosis.
- Use command-line tools to query authoritative servers directly for the most current answer.
- Document which layer of the resolution chain a fix actually addressed for future reference.
- Account for negative caching when troubleshooting a domain that recently started resolving.
- Test against several different recursive resolvers to rule out resolver-specific quirks.
- Consider switching to a public DNS resolver when diagnosing suspected ISP-level DNS issues.
- Track emerging transport options like DNS over QUIC as the ecosystem evolves.
- Verify whether a specific resolver actually performs DNSSEC validation before relying on it.
- Consider split-horizon DNS configurations when internal and external resolution results diverge.
- Account for corporate network DNS interception when troubleshooting resolution issues on managed devices.
Frequently Asked Questions
Frequently asked questions about how DNS resolution actually works.
Why does a DNS change take time to show up everywhere?
Because caching happens at multiple independent layers — browser, OS, recursive resolver — each honoring the TTL it originally fetched before checking again.
What's the difference between a recursive resolver and an authoritative nameserver?
A recursive resolver does the work of querying the DNS hierarchy on a client's behalf, while an authoritative nameserver holds the actual source-of-truth records for a domain.
Can I skip caching entirely to see the current DNS state?
Yes — querying the domain's authoritative nameservers directly bypasses caching and shows the record exactly as it currently exists.
Why would two people see different results for the same domain?
This is normal during a change and reflects different resolvers caching the old and new values at different points in their TTL cycle.
Is DNS resolution the same for every type of record?
The overall process is the same, but different record types (A, MX, TXT) may have different TTLs and caching behavior configured independently.
What is negative caching in DNS?
It's when a resolver caches the fact that a record doesn't exist, which can keep an NXDOMAIN result cached even after the record is added.
Do all DNS resolvers behave the same way?
No — caching behavior, retry logic, and even TTL honoring can vary between resolver implementations, occasionally causing inconsistent results.
Should I use my ISP's default DNS resolver or a public one?
Public resolvers often offer more consistent, well-documented behavior and can be useful for isolating whether an issue is resolver-specific.
What is split-horizon DNS?
A configuration where internal and external users receive different resolution results for the same domain, common in enterprise network setups.
Do all resolvers validate DNSSEC by default?
No — validation is resolver-dependent, so it's worth confirming explicitly rather than assuming universal support.
Can corporate networks alter DNS resolution results?
Yes — some intercept and modify responses for filtering or security purposes, which can complicate standard troubleshooting.
Analyze a Domain's DNS
Run a full DNS analysis to see every record type and resolution path for a domain.
Launch Tool →