DNS queries and who sees the sites you visit
Every time you type a web address or click a link, your device asks a question before it does anything else: “what’s the IP address for this domain name?” That question is a DNS query, and for most of the internet’s history it’s traveled in plain text. No encryption, no obfuscation, just a small packet asking “where is example.com?” and getting an answer back. If you’ve never thought about that step, you’re in good company. It’s invisible by design. But it’s also one of the more overlooked ways your browsing history gets exposed to people who aren’t you.
What a DNS query actually contains
A DNS query is narrow but specific. It doesn’t carry the contents of the page you’re about to load, and it doesn’t carry your login credentials. What it does carry is the domain name you’re resolving, sent from your device to whatever DNS resolver you’re configured to use, usually one assigned automatically by your ISP or Wi-Fi network. If you look up mail.protonmail.com, that string travels across the network unencrypted, visible to anything positioned to watch it.
This matters because domain names are often specific enough to identify what you’re doing even without seeing page content. A query for a specific clinic’s website, a particular forum, or a niche subdomain tells an observer something real, even if they never see what loads after the connection completes. Multiply that by every site you visit in a day and you get a fairly detailed shape of your browsing habits, assembled one plaintext question at a time.
Who’s actually positioned to see it
The list of people who can see your plaintext DNS queries is shorter than “everyone on the internet” but longer than most people assume.
Your ISP sees it by default, because your DNS resolver is usually theirs unless you’ve changed it. This is standard infrastructure, with no conspiracy required, and it does mean your ISP has a log of domain lookups tied to your account, and in many countries that data can be retained, sold in aggregate, or handed over under legal process.
Anyone sharing your local network segment can potentially see it too, depending on the network’s design. Open or poorly secured Wi-Fi, a compromised router, or a malicious actor on the same subnet can observe DNS traffic passing through. This is a genuinely different threat model from “my ISP logs this” and it’s the one public Wi-Fi warnings are usually gesturing at, even when they overstate the danger.
The DNS resolver itself sees every query, obviously, since answering them is its job. If you’ve switched away from your ISP’s default resolver to a public one, you’ve changed who holds that data, not whether the data exists. That’s a meaningful distinction people skip past constantly.
What encrypted DNS actually does
This is where DoH, DNS over HTTPS, comes in, alongside its older sibling DoT, DNS over TLS. Both wrap the DNS query in an encrypted tunnel between your device and the resolver you’re using. Mechanically, the query itself doesn’t change: you’re still asking “what’s the IP for this domain,” and the resolver still answers. What changes is who can read the question in transit.
With DoH or DoT enabled, someone snooping on your local network, or your ISP if it isn’t the resolver you’re querying, sees an encrypted HTTPS or TLS connection instead of a readable domain name. Browsers like Firefox and Chrome support DoH natively now, and several operating systems have added varying levels of support at the system level too. Public resolvers including Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, and Quad9’s 9.9.9.9 all offer encrypted endpoints for this purpose.
That’s a real and specific improvement for one part of the problem: it closes off passive observation of your DNS traffic by anyone between you and your resolver. It does not, by itself, make your browsing untraceable, and it’s worth being precise about why.
Where the visibility gap remains
Encrypting the question doesn’t hide the answer from everyone. Whoever operates the resolver you’re querying still sees every domain you look up, in plain text, because they have to in order to respond. Switching to encrypted DNS moves the point of visibility, it doesn’t remove it. If you route your DoH queries to your ISP’s own encrypted endpoint, you’ve encrypted the transport but the ISP still sees the queries. If you route them to a third-party resolver instead, that provider now holds the data your ISP used to hold, governed by whatever their own logging and retention practices are.
There’s also the matter of what DNS encryption doesn’t touch at all. Once your browser resolves a domain and opens a connection, the TLS handshake for that connection has historically included the domain name in a field called SNI, sent in plain text, which means an observer watching your traffic can often still see which site you’re connecting to even with encrypted DNS in place, just from watching the handshake rather than the DNS lookup. Encrypted variants of that handshake (ECH) exist and are rolling out unevenly across browsers and server support, but assuming it’s universally deployed would be premature. Separately, your ISP can always see the destination IP address you’re connecting to, since routing traffic requires that regardless of what happens at the DNS or TLS layer. IP addresses are less specific than domain names, especially when a server hosts many sites, but for smaller or dedicated hosting they can be nearly as revealing.
None of this means encrypted DNS is pointless. It closes a specific, real gap: passive local and ISP-level logging of your raw domain lookups. It just isn’t a complete answer to “does anyone know what I browse,” because DNS is one layer among several that can leak the same information.
Matching the response to the actual risk
The useful question is “who, specifically, am I trying to keep this from, and does that layer actually address them.” “How do I stop anyone from ever knowing what I look up” has no real answer. A few concrete scenarios help illustrate the difference.
If your concern is a stranger on the same coffee shop Wi-Fi passively sniffing traffic, encrypted DNS plus HTTPS (which is now the default on nearly every site) closes most of that gap on its own.
If your concern is your ISP building a browsing profile from DNS logs, switching to a DoH endpoint hosted by a different provider moves that visibility away from the ISP and parks it on whichever resolver you picked. The visibility itself survives the move. That provider’s stated logging policy becomes the thing that actually matters, not the fact that the connection to them was encrypted.
If your concern involves an adversary who can compel data from your ISP, your DNS resolver, or any other party in this chain through legal process, that’s outside what any DNS configuration can address, and outside what we’re going to speculate about here. Legal exposure depends on jurisdiction and circumstances specific enough that general advice isn’t useful, so if that’s your actual concern, that’s a conversation for a lawyer familiar with your situation, not a blog post.
A VPN changes this picture differently again, by moving both your DNS queries and your general traffic to a tunnel that terminates at the VPN provider instead of your ISP, which shifts trust to that provider rather than eliminating the need for trust somewhere. It’s a different tool solving a related but distinct problem, and like encrypted DNS, it’s one piece of a layered picture rather than a switch that turns privacy on.
The takeaway
DNS has been a quiet source of browsing exposure for as long as most of us have been online, mostly because it’s invisible and nobody thinks to check it. Encrypted DNS is a legitimate, well understood fix for the specific problem of plaintext queries being visible in transit. It’s worth turning on if your browser or OS supports it, and worth pairing with an honest look at which resolver you’re now trusting with that data. Just hold it as one layer in a stack that also includes SNI visibility, destination IPs, and whatever the resolver itself chooses to log, rather than the single fix that makes the question go away.
If you want more explainers like this that stay specific about what a given privacy tool does and doesn’t cover, you can find the rest of them on The Privacy Wire.