How Does a DNS Query Work? The Full Path From Browser to IP Address

Key takeaways

• The stub resolver on your device asks a recursive resolver; the resolver does the heavy lifting.
• The resolver walks the hierarchy: root servers, TLD servers, then the authoritative name server.
• Caching at every level, controlled by TTL, makes most lookups fast.
• Recursive means "get me the final answer"; iterative means "tell me who to ask next".
• You can watch the process with dig +trace, and DNS has security issues such as spoofing that DNSSEC and encrypted DNS address.

What is a DNS query?

Computers locate each other with IP addresses, but people use names such as www.example.com. The Domain Name System (DNS) is the distributed directory that translates names into addresses and other records. A DNS query is a question sent to this system, for example "what is the A record (IPv4 address) of www.example.com?". The protocol is documented in the IETF's DNS standards, which are indexed at the IETF RFC pages.

Who takes part in a DNS lookup?

What happens step by step?

1. Browser cache. The browser checks whether it already knows the address from a recent lookup.
2. Operating system cache and hosts file. The system checks its own cache and the local hosts file.
3. Query to the recursive resolver. The stub resolver sends a recursive query to the configured resolver and waits for a final answer.
4. Resolver cache. If the resolver has a fresh answer, it returns it immediately. This is the common case.
5. Ask a root server. If not, the resolver asks a root server about www.example.com. The root does not know the address but replies with a referral: the name servers for .com.
6. Ask the TLD server. The resolver asks a .com server, which replies with a referral to the authoritative name servers for example.com.
7. Ask the authoritative server. The resolver asks it for www.example.com and receives the A record, for example an IPv4 address, and a TTL.
8. Cache and reply. The resolver stores the answer for the TTL and sends it to your device, which also caches it.
9. Connect. The browser now opens a TCP connection to that address. DNS is finished.

Steps 5 to 7 are iterative queries made by the resolver: each server either answers or points to the next one. Step 3 is a recursive query made by your device, which asks the resolver to deliver the final answer.

What do TTL and caching do?

Every record has a time to live (TTL), in seconds, that tells caches how long to keep it. A TTL of 300 means a change you make may take up to five minutes to reach users who have cached the old value. Caching makes DNS fast and reduces load on authoritative servers. Lower the TTL before a planned migration and raise it afterwards.

How can you watch a DNS query yourself?

These commands only read public DNS data. Use a domain you own or a public one.

dig www.example.com # ask your configured resolver
dig +trace www.example.com # walk from the root down, like a resolver
dig www.example.com @1.1.1.1 # ask a specific resolver
dig NS example.com # which name servers are authoritative
dig +short MX example.com # mail servers

With +trace, the output shows each level in turn: the root server list, the answer from a root server naming the TLD servers, the TLD answer naming the domain's name servers, and finally the authoritative answer with the A record. The line for each answer includes the TTL. Compare two runs a few seconds apart using plain dig and watch the TTL count down, which shows caching at work.

How long does a lookup take?

A cached answer comes back in a few milliseconds. An uncached lookup that walks the hierarchy takes longer and depends on distance to the servers. Because most queries hit a cache, ordinary browsing rarely waits on the full path. Measure with dig, which prints the query time.

What are the DNS security issues?

• Cache poisoning and spoofing: forged responses could trick a resolver into storing a wrong address. DNSSEC signs records so resolvers can verify them.
• Eavesdropping: traditional DNS is unencrypted. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the path between you and the resolver.
• DNS tunnelling and data exfiltration: data hidden in queries. Monitor unusual query volume and long random subdomains.
• Hijacking: attackers change a domain's name server settings. Protect registrar accounts with MFA and registry locks.
• DDoS: overloading DNS servers. Use redundancy and anycast.

Common mistakes and misunderstandings

• Confusing the recursive resolver with the authoritative server.
• Expecting a DNS change to appear instantly everywhere.
• Forgetting that the hosts file and caches can override DNS.
• Assuming HTTPS hides DNS lookups; they are separate unless DoH or DoT is used.

Next steps

For related reading, see DNS and DNSSEC and what happens when you type a URL. To study networking in depth, see our computer networking course.