resolvers

Overview

When you type a name, something has to go find its IP address. That something is a chain of resolvers and name servers working together. This lesson explains the roles in DNS resolution and how a query travels from your device to an authoritative answer.

Learning objectives

• Distinguish the roles of stub resolver, recursive resolver, and authoritative server.
• Describe recursive vs iterative resolution.
• Trace a query through the resolver hierarchy.

Core concept

Several players cooperate to resolve a name:

• Stub resolver — the small client on your device that asks a configured resolver for answers.
• Recursive resolver (recursor) — a server (often run by your ISP or a public provider) that does the legwork of finding the answer on your behalf, then caches it.
• Root, TLD, and authoritative servers — the hierarchy of name servers that hold the actual delegation and records. The authoritative server for a domain gives the definitive answer.

Recursive resolution means the recursor keeps asking on your behalf until it has the answer; iterative resolution means each server it asks returns a referral to the next server to try.

How it works

Your stub resolver asks the recursive resolver for www.example.com. If the recursor does not already have it cached, it queries iteratively down the hierarchy: it asks a root server (which refers it to the .com TLD servers), then the TLD servers (which refer it to example.com's authoritative servers), then the authoritative server (which returns the actual IP). The recursor caches the result and returns it to your device.

Practical example

You visit a site for the first time. Your device's stub resolver hands the name to your configured recursive resolver. The recursor walks root → .com → example.com authoritative server, gets the IP, caches it, and replies to you. The next visit is far faster because the recursor already has the answer cached — no full walk needed.

Cybersecurity relevance

Resolvers are a security control point and a target. A malicious or compromised resolver can return poisoned answers, sending users to attacker-controlled servers. Choosing trustworthy resolvers, and technologies that authenticate answers (like DNSSEC) or encrypt queries (DNS over HTTPS/TLS), protects this step. Analysts also monitor recursive resolver logs to spot suspicious lookups (e.g. to known-malicious domains).

Common mistakes

• Confusing the recursive resolver with the authoritative server — the recursor finds the answer; the authoritative server owns it.
• Thinking your device walks the whole hierarchy — normally the recursive resolver does that work for you.
• Overlooking resolver trust — the resolver you use can shape (or falsify) every answer you get.

Key takeaways

• Resolution involves a stub resolver (your device), a recursive resolver (does the legwork and caches), and the root/TLD/authoritative hierarchy (holds the records).
• Recursive resolution has the recursor find the full answer; iterative resolution returns referrals step by step.
• The resolver is a critical trust and monitoring point, targeted by poisoning and protected by DNSSEC/encrypted DNS.

Check your understanding

• What is the difference between a recursive resolver and an authoritative name server?
• Trace, in order, the servers a recursive resolver contacts to resolve a brand-new .com name.