Why your ISP's default DNS is a privacy problem

Almost every connection your devices make starts with a question: what is the IP address for this name? Before a single byte of your encrypted web traffic moves, your laptop, phone, TV and thermostat all ask a resolver to translate a hostname into an address. By default, that resolver belongs to your internet provider — you never chose it, you rarely think about it, and it sees the question every time. HTTPS hid the content of your browsing years ago. The lookups that precede it are still, for most households and small offices, sent in the clear to a server you don't control.

That matters more than it sounds. A list of the domains a network resolves, with timestamps, is a remarkably complete picture of what the people behind that network do all day. You don't need the contents of the pages to know someone visited a bank, a dating site, a job board, a pharmacy portal, and a competitor's careers page — all within twenty minutes, from a phone that joined the Wi-Fi at 8:55 every weekday. The default DNS path leaks exactly that, and this article is about why, and what actually fixes it.

What the resolver operator can see

A DNS resolver is in a privileged position: it is the one component that, by design, must learn the name of everything you connect to. Encryption of the page content (TLS) doesn't change that — the name resolution happens first and separately. From the stream of queries alone, the operator can reconstruct a great deal.

• Your full browsing graph. Not just the top sites, but the third parties they pull from — analytics, CDNs, embedded widgets, API back-ends. The pattern of those sub-requests often identifies the exact app or page, even when the main domain is generic.
• Timing and routine. Queries are timestamped. When you wake, when you commute, when you work, when you sleep, when you binge a series on a Friday night — all visible as a daily and weekly rhythm.
• Device inference. Many devices phone home to vendor-specific domains on a fixed cadence. A smart TV, a games console, a particular brand of doorbell, a health wearable's companion app — each has a recognisable fingerprint of lookups, so the operator can count and classify the devices on your network without ever touching them.
• Life events. A sudden cluster of lookups to moving-company, mortgage, baby-product or job-search domains is a signal. Aggregated across millions of subscribers, these signals have commercial value.

Clear-text on port 53, and who else is watching

Classic DNS is defined in RFC 1035 and runs over UDP (and TCP) on port 53 with no encryption and no authentication. That has two consequences that are easy to underestimate.

First, the operator isn't the only party who can read your queries — anyone on the path can. On shared Wi-Fi, on a compromised home router, at an intermediate network hop, a passive observer sees the plaintext question and the plaintext answer. They don't need to break anything; the protocol simply hands the data over. This is the same on-path visibility that drove the web to HTTPS, except DNS mostly never got the memo.

Second, because there's no authentication, that same on-path position allows tampering, not just snooping. An attacker — or an over-eager intermediary — can forge a reply and send your device to the wrong address. Encrypted DNS transports were created precisely to close both gaps at once: confidentiality and integrity between your device and the resolver you chose.

Default path (what most networks do today):

  device ──(plaintext :53)──> ISP resolver ──> the internet
            ▲
            └─ readable + forgeable by anyone on the path

Encrypted path (what you want):

  device ──(encrypted)──> resolver you trust ──> the internet
            ▲
            └─ sealed and authenticated end to end

Logging, retention and lawful access — the boring realities

Snooping by a stranger on the café Wi-Fi is the dramatic case. The quieter, more systemic issue is what the resolver operator does with the queries it is supposed to receive. Three realities apply to default ISP DNS in much of the world, and none of them require anyone to be acting in bad faith.

We're keeping this general on purpose: practices differ enormously by country and by company, and blanket accusations are usually wrong. The honest framing is structural rather than moral. When you use the default resolver, the record is created and held somewhere outside your control, and what happens to it depends on policy and law you didn't write. That is the privacy problem, independent of any one operator's good intentions.

NXDOMAIN hijacking and ad injection

There's a more visible side effect that has nothing to do with surveillance. When you mistype a domain or visit one that doesn't exist, a correct resolver returns NXDOMAIN — "this name does not exist" — per RFC 1035. Some ISP resolvers, instead of returning that error, substitute the IP of a search-and-advertising landing page they own. Your browser then loads their page, full of ads, where it should have shown a clean error.

This practice — historically common enough to get its own name, "DNS error-page monetisation" — breaks more than your sense of trust. It corrupts non-browser software that legitimately relies on getting NXDOMAIN back: mail servers, anti-spam checks, and security tools all misbehave when "no such domain" is silently rewritten into "here, have an ad server." It also means the resolver is actively editing your answers, which is the integrity problem from earlier, dressed up as a feature.

A resolver that lies to you about a domain not existing is, by definition, a resolver you cannot use to reason about anything. The fix is not to hope it stops; it's to stop asking it.

What changing your resolver does — and doesn't — fix

The obvious move is to point your devices at a different resolver. That helps, but only if you understand the two halves of the problem, because changing who you ask and changing how you ask are different fixes.

Who you ask: trust moves, it doesn't disappear

Switching from your ISP to another resolver changes which operator sees your queries. It does not make the visibility go away — it transfers it. If the new operator logs, retains, or monetises just as aggressively, you've swapped one envelope-reader for another, possibly a larger one with a bigger appetite for data. Picking a resolver is fundamentally a question of whose policy you'd rather live under, which is why the destination matters as much as the act of switching.

How you ask: encryption is the other half

Even a trustworthy resolver does nothing about the on-path observers from earlier if you reach it over plaintext port 53. To close that gap you need an encrypted transport between your device and the resolver — DNS over TLS, DNS over HTTPS, or DNS over QUIC, depending on what your clients support. Only then are your queries sealed against the café Wi-Fi, the compromised router, and the intermediate hop.

It's worth naming one thing encrypted DNS still leaks: when your browser opens the TLS connection after the lookup, the destination hostname can appear in the connection setup (the SNI field), and the destination IP is visible to your network regardless. Encrypted DNS is necessary, not sufficient, for total metadata hiding — but it removes the single richest, most complete, most easily-logged signal: the ordered list of every name you resolve.

Choosing a resolver you actually trust

So you accept that DNS privacy is a question of operator trust plus encrypted transport. How do you pick? A few criteria that survive scrutiny, regardless of which product you land on:

1. A clear, narrow retention policy. Prefer an operator that states what it keeps, for how long, and why — and keeps as little as possible. Vague policies are a tell.
2. Encrypted transport, on by default. The resolver should speak at least one of DoT, DoH or DoQ, and your clients should use it for every query, not just some.
3. No answer tampering. It should return honest NXDOMAIN for non-existent names and never inject landing pages.
4. Jurisdiction you can reason about. Where the logs live determines who can compel them. That's a legitimate selection criterion, not paranoia.
5. Control over filtering. If the resolver also blocks ads, trackers or malware, you should be able to see and adjust what it blocks — filtering you can't inspect is just a different operator deciding for you.

Why operator choice — including yourself — is the real answer

There's a reason the strongest privacy posture is to run the resolver yourself, or to use one operated by someone whose incentives align with yours rather than with an ad market. When you control the resolver, you control the log. You decide whether queries are written down at all, how long anything is kept, and who can ever read it. The retention policy is no longer a paragraph in someone's terms of service — it's a setting you own.

For a household or a small business, that used to mean wrangling raw resolver software. It doesn't anymore. A self-hosted filtering resolver gives you encrypted transport to your own box, honest answers, threat-intelligence filtering you can audit, and logs that never leave your premises unless you send them. The query graph still gets created — it has to, that's how DNS works — but it gets created somewhere you govern, under a retention policy you wrote, instead of on infrastructure built to monetise it.

The default resolver isn't a privacy problem because your ISP is evil. It's a privacy problem because the most revealing record about your network gets created in a place you don't control, governed by rules you didn't write. The fix is not outrage — it's ownership: choose the operator, encrypt the path, and keep the log where it belongs.