DNS resolution is the process of converting a domain name into an IP address. While it appears instantaneous to users, it involves a carefully orchestrated sequence of queries across a distributed global infrastructure. Understanding the resolution process helps you diagnose failures, plan migrations, and appreciate why DNS changes take time to propagate.
What Happens When You Type a URL?
The moment you enter https://showdns.net and press Enter, your browser needs to know the IP address of the server hosting that site before it can open a connection. Here is the sequence of events:
- URL parsing — the browser extracts the hostname (
showdns.net) from the full URL. - Browser DNS cache check — if recently resolved and the TTL has not expired, the cached IP is used immediately.
- OS stub resolver — if not in the browser cache, the OS resolver checks the hosts file, then its own cache.
- Recursive resolution — if still unresolved, a query goes to the configured recursive resolver.
- TCP/IP connection — once the IP is known, the browser opens a connection and sends the HTTP request.
Recursive vs. Iterative Resolution
There are two fundamental modes of DNS resolution: recursive and iterative. These describe how the work is distributed between the client and the servers.
Recursive Resolution
In recursive resolution, the client (your stub resolver) sends a query to a recursive resolver and expects a complete answer back. The recursive resolver takes full responsibility for following the referral chain through root, TLD, and authoritative nameservers. The client does nothing further — it simply waits for the final answer.
This is the model used by everyday internet traffic. Your device queries a recursive resolver (like 1.1.1.1) and receives a finished answer, with all intermediate steps handled transparently.
; Recursive query — client asks once, gets a full answer
Client ──► Recursive Resolver: "What is the IP for showdns.net?"
Recursive Resolver ──► [navigates the hierarchy]
Recursive Resolver ──► Client: "showdns.net is at 93.184.216.34"Iterative Resolution
In iterative resolution, each DNS server only provides the best answer it has, which may be a referral to another server rather than a final answer. The querying entity must then follow that referral itself, repeating the process until it reaches an authoritative answer.
Recursive resolvers use iterative queries when communicating with root and TLD nameservers. They ask the root server, receive a referral, query the TLD server, receive another referral, and finally query the authoritative server to get the answer.
; Iterative queries — resolver follows each referral itself
Resolver ──► Root Server: "showdns.net?"
Root Server ──► Resolver: "I don't know, ask .net TLD servers: a.gtld-servers.net"
Resolver ──► TLD Server: "showdns.net?"
TLD Server ──► Resolver: "I don't know, ask: ns1.showdns.net"
Resolver ──► Authoritative NS: "showdns.net?"
Authoritative NS ──► Resolver: "showdns.net → 93.184.216.34"Types of DNS Resolvers
There are several categories of resolvers, each serving a different role:
Stub Resolver
A stub resolver is the minimal DNS client built into your operating system. It knows only how to send queries and receive answers — it cannot follow referrals or navigate the DNS hierarchy. It delegates all hard work to a recursive resolver.
Recursive Resolver (Full-Service Resolver)
A recursive resolver performs the complete lookup process. It maintains a large cache, follows referrals through the hierarchy, and returns final answers to clients. Examples include your ISP's resolver, Google Public DNS (8.8.8.8), and Cloudflare DNS (1.1.1.1).
Forwarding Resolver
A forwarding resolver receives queries from local clients and forwards them to another recursive resolver rather than performing resolution itself. Common in corporate environments where all DNS traffic is routed through an internal server before reaching the internet.
Authoritative Nameserver
An authoritative nameserver holds the official records for a domain. It answers queries with final, authoritative answers (not referrals). When you use a DNS hosting provider like Cloudflare or AWS Route 53, their servers act as authoritative nameservers for your domain.
The Role of TTL in DNS Resolution
Every DNS record carries a TTL (Time to Live) value, measured in seconds. This value tells resolvers and clients how long they may cache the answer before they must re-query the authoritative nameserver.
TTL directly affects several aspects of the resolution process:
- Speed — high TTLs mean more cache hits and fewer queries, reducing latency.
- Propagation time — when you change a DNS record, the old value remains cached until existing TTLs expire. Lower TTLs accelerate propagation.
- Server load — very low TTLs dramatically increase query volume to your authoritative nameserver.
- Failover time — in a disaster recovery scenario, a lower TTL allows traffic to shift to a backup server more quickly.
Negative Caching
DNS also caches negative responses — that is, the fact that a record does not exist. When a resolver queries for a domain that returns NXDOMAIN (no such domain) or NODATA (record type does not exist), that negative response is cached for the duration specified in the zone's SOA record (minimum field). This prevents repeated fruitless queries for the same non-existent name.
DNSSEC and Its Effect on Resolution
When DNSSEC is enabled on a domain, the resolution process includes an additional validation step. The recursive resolver retrieves cryptographic signatures (RRSIG records) alongside the DNS data and validates them using public keys (DNSKEY records) obtained from the authoritative nameserver. If the signature is valid, the answer is trusted; if not, the resolver returns a SERVFAIL error. This prevents cache poisoning attacks but adds a small amount of overhead to resolution.
Verifying DNS Resolution in Practice
You can observe DNS resolution in action using command-line tools. The dig command (available on Linux and macOS) provides detailed output of the resolution process:
# Query for an A record with full detail
dig showdns.net A
# Trace the full resolution path step by step
dig showdns.net A +trace
# Query a specific resolver
dig @1.1.1.1 showdns.net AFor a browser-based alternative with no setup required, use the ShowDNS DNS Lookup tool. To check how a record has propagated across global resolvers, use the DNS Propagation Checker.
Frequently Asked Questions
What is the difference between a recursive and an iterative DNS query?
In a recursive query, the server you ask takes full responsibility for finding the answer, following all necessary referrals, and returning a complete response. In an iterative query, the server returns the best answer it has — which may be a referral to another server — and leaves the client to continue the lookup. Your device uses recursive queries; recursive resolvers use iterative queries internally.
What does NXDOMAIN mean?
NXDOMAIN means "Non-Existent Domain." A DNS server returns this response when the queried domain name does not exist at all. It is different from NODATA, which means the domain exists but has no records of the requested type. NXDOMAIN responses are cached based on the SOA record's minimum TTL.
How does split-horizon DNS work?
Split-horizon DNS (also called split-brain DNS) serves different DNS responses depending on the source of the query. For example, internal company users might resolve app.example.com to an internal IP, while external users get a public IP. This is implemented using separate DNS zones or view configurations on the authoritative nameserver.
Why does DNS resolution sometimes fail?
DNS resolution can fail for several reasons: the authoritative nameserver is unreachable or misconfigured, the domain has expired, there is a network problem between the resolver and the nameserver, the DNSSEC signature is invalid, or the resolver itself is experiencing issues. The DNS Propagation Checker can help identify whether a problem is isolated or global.
Can I force my device to bypass DNS caching?
Yes. You can flush your OS DNS cache (on Windows: ipconfig /flushdns; on macOS: sudo dscacheutil -flushcache; on Linux: varies by service). Browsers also have their own caches — in Chrome, visit chrome://net-internals/#dns to clear it. However, you cannot force other resolvers (such as your ISP's) to flush their caches.