Fundamentals

DNS Privacy: What It Protects and Its Limits

By Daniel Sardá · Published on October 22, 2026

7 min read1,526 words

Encrypted DNS limits who can read our queries in transit, but it neither removes the need to trust intermediaries nor hides all internet activity.

Before a website appears on screen, something less visible usually happens: an application asks which address corresponds to the name we want to open. That query can reveal information about our interests and habits even before the page has finished loading. Who can see it, and what changes when we use encrypted DNS?

The short answer is that DNS privacy reduces the exposure of those queries, especially on their path between the device and the resolver. It is a concrete but limited improvement: it does not make browsing anonymous, hide all traffic, or remove the need to trust an intermediary.

Understanding those limits makes for better choices and avoids a common confusion: protecting one part of a communication does not make the whole thing invisible.

What happens when we look up a domain

People remember names such as `example.org`; networks need other information to locate the corresponding service. The Domain Name System, or DNS, makes that translation possible.

In a typical operation, the device sends the question to a recursive resolver. It may answer from cached information or query other servers until it obtains an answer. Caching means that the exact path can vary, but the essential function remains the same: resolving the requested name.

Here, “private DNS” means protecting a user's queries. The expression is also used for internal DNS zones in a company or organization, which is a different matter.

The privacy problem is not that a domain name is secret. Many DNS records are public. What is sensitive is the ability to associate what was queried, from which origin, and at what time. RFC 9076 on DNS privacy considerations explains that queries and their patterns can be linked to people or devices.

Key idea: A domain can be public while the sequence of a person's queries remains private information.

An isolated query does not, by itself, prove that someone visited a page or necessarily reveal their intent. Applications make background queries, one page may call several domains, and some information may come from a cache. Still, a sequence of queries can suggest routines, schedules, services used, or sensitive interests.

Who can observe what

It helps to distinguish among the actors, because they do not all receive the same information or occupy the same place in the chain.

With traditional unencrypted DNS, someone able to observe the network between the device and the resolver—such as a local-network operator or an internet service provider—may read or interfere with the queries crossing that segment. Actual visibility depends on the configuration and the data's real path.

The resolver occupies a different position. It has to receive the question in order to answer it, so it can potentially see the queries it processes. It may keep logs or apply data-minimization measures; that depends on both its technical design and its operator's practices.

Further along are the authoritative servers, which hold information about domains. Techniques such as QNAME minimization, described in RFC 9156, reduce how much of a name is disclosed to particular servers during resolution. They do not hide the query from the resolver to which we send it.

The distinction matters: a measure can protect against observers along the path without protecting against the recipient of the query.

What DoT and DoH change

The two best-known forms of encrypted DNS are DNS over TLS (DoT) and DNS over HTTPS (DoH). Both create an encrypted channel between the client and a compatible resolver, though they use different transports.

DoT sends DNS messages inside a TLS connection. RFC 7858 specifies this mechanism and assigns port 853 by default. DoH, defined in RFC 8484, exchanges DNS queries and responses over HTTPS through a configured endpoint.

In both cases, encryption makes it harder for a passive observer between the device and the resolver to read the query's contents. It also protects against modifications on that channel when the connection is correctly authenticated.

It does not follow that DoH is always more private than DoT, or the reverse. Actual privacy depends on the implementation, the metadata available, the resolver chosen, and the risk one is trying to reduce. DoH also operates in the HTTP environment and may share some of its correlation risks.

Key idea: DoT and DoH protect one leg of a query's journey. They do not automatically encrypt every later stage of resolution or all browsing traffic.

They should not be confused with DNSSEC either. DNSSEC helps verify the authenticity and integrity of DNS data, but it is not intended to conceal queries. Privacy, integrity, and authenticity address related but non-interchangeable problems.

What encrypted DNS does not hide

The improvement is real precisely because it can be described without exaggeration. Encrypted DNS has several limits:

• The resolver receives the query. The channel prevents third parties from easily reading it on that leg, but the service resolving it needs to know it.
• Other metadata remains. An internet service provider may still see IP addresses, volumes, connection times, and connection duration even when it cannot read protected DNS content.
• Subsequent traffic is a separate matter. Resolving a domain and connecting to the service are different operations. Encrypting the first does not by itself protect all of the second.
• Correlation remains possible. Connection timing and patterns can support inferences, especially when different sources of data are combined.
• It does not provide anonymity. DNS encryption does not necessarily separate the query from the identity, account, IP address, or device that originated it.
• It does not guarantee protection from censorship, malware, or tracking. Those problems require different measures and depend on more layers of the system.

For example, someone can make it harder for a local-network operator to read a sensitive domain they query. The chosen resolver still receives that request, and the internet service provider can observe a later connection to a particular IP address. Each actor sees a different part; no single tool erases every signal.

Key idea: “Encrypted” describes how the channel is protected. It does not by itself say who keeps data, for how long, or with whom it is shared.

Encryption also means choosing whom to trust

When the network's resolver is replaced with another service, trust does not disappear: it shifts. Exposure to the local network or internet service provider may decline while a set of queries becomes concentrated with a new operator.

This does not mean every change is pointless. It means the assessment cannot end with the presence of a padlock or the protocol's name. RFC 8932, written for DNS privacy service operators, emphasizes practices such as data minimization, limited retention, and transparency.

From the perspective of individual liberty, the central question is informed control over data that can describe our conduct. That control requires options, but also understandable information about intermediaries. A technical choice is genuine when a person can know what it protects, what they give in return, and what risks remain.

How to assess a private DNS option

There is no universal answer, because people face different actors and risks. Before choosing a configuration or resolver, it is useful to ask:

1. Whom am I seeking protection from? A shared Wi-Fi network, an internet service provider, the resolver itself, and an adversary able to correlate traffic do not present the same problem.
2. Which segment is encrypted? Check whether the device or application is actually using DoT or DoH to reach the intended resolver, and what happens if the protected connection fails.
3. What data does the operator retain? Logs, retention periods, stated purposes, and terms for sharing information all matter.
4. How is the service funded and governed? Incentives and accountability help assess whether a privacy policy is credible.
5. Where does it operate, and under which rules? Jurisdiction may shape legal duties and available remedies.
6. Does it concentrate more information than necessary? A widely used service may offer technical capacity while also collecting many users' queries in one place.

These questions form a small threat model: they identify what information we want to protect, who might obtain it, and what cost or complexity we are prepared to accept. They also keep us from choosing a tool based on an abstract promise of “maximum privacy.”

A useful layer, not a magic one

DNS privacy is not about hiding the fact that domains exist. It is about limiting the exposure of queries and making it harder for third parties to link them to a person or device. DoT and DoH help protect the journey to the resolver; other measures address integrity, subsequent traffic, or data reduction at other stages.

The reasonable choice depends on the actual risk. For someone connecting to networks they do not control, encrypting queries can reduce an immediate exposure. For someone concerned about accumulated histories, the resolver's policy matters as much as the protocol. And against adversaries able to correlate traffic, additional protections will be needed.

Digital privacy is built in layers. Encrypted DNS is one of them: valuable when understood precisely, insufficient when mistaken for invisibility.