Same lookup, same answer. The only difference is how much each server in the chain gets told along the way.
It is a quiet, sensible idea: a server that only knows where the next step lives has no reason to be told the whole destination. Minimisation just stops volunteering it.
What QNAME minimisation is
When your resolver looks up a name it does not have cached, it walks the hierarchy described in how DNS actually works: it asks a root server, then a top-level domain server, then the domain's own server. The catch is in the old habit of how it asked. By default the resolver put the whole name, www.example.com, into every one of those questions, even though the root only needs to hear com to point it onward, and the .com servers only need example.com.
QNAME minimisation, written up as RFC 7816, changes the habit. The resolver asks each level only for the part it is responsible for: the next label down. The root is asked about com, the .com servers about example.com, and only the final, authoritative server for the domain is told the full www.example.com, because that is the one server that actually has to know it. Same walk, same answer, far less spilled along the way.
Why it matters
The root and the top-level domain servers are operated by third parties you never picked and never interact with directly. They exist to do one narrow job: say where the next level lives. There is no reason they should accumulate a record of the exact hostnames people are trying to reach, yet without minimisation that is precisely what the full-name habit handed them, query after query.
Minimisation shrinks that exposure to the few who genuinely need it. The root learns only that someone wanted something under .com, which it could already infer. The .com operator learns the domain but not which host or page. The full name reaches only the domain's own server, which was always going to receive it because it has to answer for it. The circle of who knows what you looked up gets as small as the system allows.
How it fits with the other protections
It is worth seeing where this sits, because it is a different hop from the one most people think of. Encrypted DNS protects the link between you and your resolver, so the network beside you cannot read your lookups. QNAME minimisation protects the next hops, between your resolver and the servers it has to consult, so those servers learn less. One seals the question from the people near you; the other trims the question for the people your resolver must ask.
It also points the opposite way from EDNS Client Subnet, which can add a slice of your address to those upstream questions. A resolver built around privacy tends to do both of the quiet, right things: minimise the name it sends, and keep your subnet to itself. Together they decide how much of you travels onward once your encrypted query arrives, which is the part of the picture encryption alone does not settle.
What it does not do
Minimisation is a reduction, not a disappearance. The authoritative server for the domain still sees the full hostname, because it is the one that answers for it; there is no way around that and no need to want one. Your resolver also still sees everything, as it must to do the work, which is why which resolver you trust remains the central choice, the theme running through what a resolver is.
And because it is a behaviour of the resolver, not a setting on your device, you do not switch it on yourself; you get it by using a resolver that does it. The good news is that it is now common and quietly on by default in the well-run ones. If you run your own, it is a single line, as shown in the validating resolver runbook.
Less told, at every step
Encrypted DNS keeps your lookups unreadable on the wire; a resolver that minimises the name keeps the servers it must ask from learning more than they need. Set the first in a couple of minutes.
Set up encrypted DNSRelated: how DNS actually works, EDNS Client Subnet, and build a validating resolver.