"DNS resolver" gets used to describe two related but distinct things — the small piece of software on your own device that sends lookup requests, and the separate, more capable server that actually performs the lookup work. Keeping the two straight clarifies a lot of DNS discussion.
The stub resolver: on your device
Your operating system includes a lightweight stub resolver — its only job is to package up a lookup request and send it to a configured recursive resolver. It doesn't perform the actual multi-step DNS hierarchy walk itself; it delegates that work entirely.
The recursive resolver: doing the real work
The recursive resolver — run by your ISP, a VPN provider, or a public service like the ones covered in Public DNS Resolvers — receives your stub resolver's request and does the actual work: checking its own cache, and if needed, querying the broader DNS hierarchy (root, TLD, and authoritative servers) to find an answer, then returning it and typically caching it for future requests.
Why this distinction matters
When people talk about "changing their DNS," they mean changing which recursive resolver their stub resolver is configured to ask — not changing anything about the stub resolver itself, which stays the same regardless. Understanding this clarifies why DNS configuration happens at the "which resolver to use" level, not at some deeper protocol level.
FAQ
Can I run my own recursive resolver?
Yes — software like Unbound or BIND lets technically inclined users run a full recursive resolver locally rather than delegating to a third party, trading convenience for direct control over the entire lookup process.