How Encrypted DNS Resolvers Shift Trust Without Eliminating It
Every time you type a domain name into your browser, your device sends a DNS query. By default, that query travels in plaintext—readable by any network hop along the way. Encrypted DNS protocols like DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over QUIC (DoQ) wrap that query in a cryptographic layer. But here’s the catch: the envelope still has a destination address, and the recipient still reads the message. Trust doesn’t vanish. It just packs its bags and moves to a new address.
For the people who design, audit, or govern infrastructure—the core readership of this blog—the interesting question isn’t whether encryption is good. It’s what happens to the trust model when the postcard becomes an envelope. The answer pulls in resolver consolidation, policy enforcement, and the quiet power of default settings.
The Old Postcard Model: Why Unencrypted DNS Became a Liability
Traditional DNS runs over UDP port 53 with zero confidentiality. Every query—whether for a bank, a health portal, or a news site—is visible to the recursive resolver, the authoritative server, and any network operator in between. That visibility propped up a whole ecosystem: ISP content filtering, ad-targeting data collection, government-mandated blocking. It also made DNS a handy vector for surveillance and manipulation.
The IETF responded by standardizing DNS over TLS (DoT) in 2016 and DNS over HTTPS (DoH) in 2018. Both encrypt the query between client and resolver, blocking on-path observers from reading or tampering with the request. DoT uses a dedicated port (853), so it’s easy to spot and block. DoH blends DNS into the HTTPS stream on port 443, making it tough to distinguish from regular web traffic. That distinction matters a lot for network admins who lean on DNS visibility for security or policy enforcement.
Encrypted DNS isn’t a privacy cure-all. The resolver still sees the query and the client IP address. The authoritative server still sees the resolver’s query. Encryption protects the path, not the endpoints. The trust that was once scattered across multiple intermediaries now lands squarely on the resolver operator.
Resolver Concentration: The New Gatekeepers
When DNS was unencrypted, your ISP usually picked the resolver. With encrypted DNS, users can choose any resolver that supports the protocol. In practice, a handful of public resolvers dominate: Google Public DNS, Cloudflare’s 1.1.1.1, Quad9, and OpenDNS. Each operates under a different privacy policy, logging practice, and threat intelligence model.
This concentration raises fresh governance questions. A user who ditches an ISP resolver for a public encrypted one might escape one kind of surveillance and walk straight into another. The ISP can’t see the queries anymore, but the public resolver can. The difference lies in the resolver’s stated policies, its jurisdiction, and its business model. Google’s resolver, for instance, logs temporary data for debugging and security but claims not to correlate it with user accounts. Cloudflare commits to not writing query IP addresses to disk and hires external auditors to verify. Quad9 blocks known malicious domains by default, making a security decision on the user’s behalf. Each choice is a governance decision, not just a technical one.
This shift also hits enterprise and institutional networks. Many organizations rely on DNS filtering to enforce acceptable-use policies, block malware, or comply with regulations. When a device uses an encrypted resolver outside the organization’s control, that visibility evaporates. The trust once placed in internal DNS infrastructure now shifts to an external provider—or to the device manufacturer that pre-configures the resolver.
Protocol Politics: DoH, DoT, and the Browser Battles
The choice of protocol is itself a governance decision. DoH embeds DNS queries in HTTPS, making them indistinguishable from web traffic. That design was intentional: it prevents network operators from blocking or redirecting DNS queries. But it also bypasses existing DNS-based security controls. A network that uses DNS sinkholing to block malware domains can’t see DoH queries unless it performs TLS inspection—a practice that brings its own privacy and performance headaches.
DoT, by contrast, uses a dedicated port. Network admins can choose to allow or block it. That makes DoT more compatible with enterprise policy enforcement but also more susceptible to censorship. The choice between DoH and DoT isn’t just a technical toggle; it’s a statement about who should control DNS resolution on a network.
Browser vendors have become central actors in this shift. Mozilla and Google both enable encrypted DNS by default in certain configurations. Mozilla’s approach uses a curated list of resolvers that meet specific privacy requirements. Google’s Chrome automatically upgrades to DoH if the user’s configured resolver supports it. These defaults shift trust from the operating system and the local network to the browser vendor and its chosen resolver partners. For users, this happens largely invisibly.
The IETF’s work on Discovery of Designated Resolvers (DDR) and Discovery of Network-designated Resolvers (DNR) tries to give network operators a way to signal their preferred encrypted resolvers. But adoption is slow, and the power of defaults remains strong. The entity that controls the application—the browser—often has the final say.
Policy Enforcement and the Erosion of Local Control
In many organizations, DNS is a policy enforcement point. Schools use DNS filtering to block adult content. Enterprises use it to prevent access to known phishing domains. Governments mandate DNS-based blocking of copyright-infringing or politically sensitive sites. Encrypted DNS complicates all of these practices.
When a device uses an external encrypted resolver, local DNS policies become invisible to it. The device simply bypasses the local resolver and its associated policies. This can be a feature for users seeking to avoid censorship, but a bug for network administrators responsible for security or compliance. The tension isn’t new—VPNs and proxy servers have long offered similar bypasses—but encrypted DNS makes it a default behavior for millions of users who never consciously opted in.
Some resolver operators have responded by building policy into their services. Quad9 blocks known malicious domains. Cloudflare offers malware blocking and family-friendly filtering as configurable options. These features shift policy enforcement from the local network to the resolver. The trust decision moves from “my network administrator sets the rules” to “my resolver operator sets the rules.” For some users, this is an improvement. For others, it’s a loss of local autonomy.
Jurisdiction and the Geography of Trust
When a user in Germany sends a DNS query to a resolver operated by a US-based company, which country’s laws apply to that data? The answer isn’t straightforward. The resolver may be subject to US law, the law of the country where its servers sit, and international agreements. The user may be protected by GDPR in Europe, but those protections depend on the resolver’s compliance and the enforceability of cross-border data protection.
This jurisdictional ambiguity isn’t unique to DNS. It mirrors broader debates about cloud services, data localization, and the reach of national surveillance laws. But DNS is particularly sensitive because it reveals the full pattern of a user’s internet activity. A resolver that logs queries—even temporarily—holds a detailed map of a user’s online life. The trust placed in that resolver isn’t just about technical competence; it’s about legal and political accountability.
Some resolver operators have responded by incorporating in privacy-friendly jurisdictions. Quad9, for example, is based in Switzerland and subject to Swiss data protection law. Others, like Cloudflare, publish transparency reports and submit to external audits. These are meaningful steps, but they don’t eliminate the trust requirement. They shift it from a technical guarantee to an institutional one.
What Encrypted DNS Does Not Solve
Encrypted DNS protects the confidentiality and integrity of queries between the client and the resolver. It does not protect against the resolver itself. It does not hide the client’s IP address from the authoritative name server. It does not prevent traffic analysis—an observer can still see which IP addresses the client connects to after the DNS lookup. And it does not encrypt the subsequent communication between the client and the destination server. That remains the job of TLS, VPNs, or other transport-layer protections.
This limited scope is important. Encrypted DNS is often marketed as a privacy tool, but it’s more accurately a confidentiality tool for one specific leg of the journey. It prevents the local coffee shop Wi-Fi operator from seeing your DNS queries, but it does not prevent the coffee shop from seeing which IP addresses you visit. It prevents your ISP from modifying DNS responses, but it does not prevent the ISP from throttling or blocking traffic to those IP addresses. The trust that encrypted DNS removes from the local network is partially replaced by trust in the resolver, and partially left unaddressed.
Practical Implications for Infrastructure Governance
For those responsible for network policy, encrypted DNS presents a series of practical questions. Should the network allow DoH, DoT, or both? Should it provide its own encrypted resolver? Should it block known public resolvers? Should it rely on application-level controls instead of DNS-based ones? The answers depend on the network’s threat model, its regulatory environment, and its relationship with users.
In a corporate network, the default answer is often to block external encrypted DNS and provide an internal resolver that supports encryption. This preserves visibility and policy control while still protecting queries on the local network. In a public Wi-Fi setting, the calculus is different. Users may reasonably distrust the network operator and prefer to use their own resolver. In a home network, the choice is often left to the device manufacturer or the ISP, with little transparency for the end user.
These scenarios highlight a recurring theme in protocol politics: the same technology that protects one party can disempower another. Encrypted DNS protects the user from the network operator, but it also protects the user from the network operator’s security policies. The trust that is shifted is not neutral. It has winners and losers.
Frequently Asked Questions
Does encrypted DNS make me anonymous online?
No. Encrypted DNS hides your queries from on-path observers, but the resolver still sees them. Your ISP can still see which IP addresses you connect to after the DNS lookup. Anonymity requires additional tools, such as VPNs or Tor, and even those have limitations.
Which encrypted DNS protocol is better: DoH or DoT?
Neither is universally better. DoH blends into HTTPS traffic, making it harder to block or identify, which can be good for privacy but bad for network management. DoT uses a dedicated port, making it easier to monitor and control. The right choice depends on your threat model and who you trust to manage the network.
Can my ISP still see my browsing if I use encrypted DNS?
Your ISP cannot see the DNS queries themselves if they are encrypted, but they can still see the IP addresses you connect to afterward. They can also infer which sites you visit based on traffic patterns, a technique called traffic analysis. Encrypted DNS improves confidentiality but does not provide complete privacy.
Who decides which encrypted DNS resolver my device uses?
It depends on the device and browser. Some browsers, like Firefox, can be configured to use a specific DoH resolver. Chrome can automatically upgrade to DoH if the system resolver supports it. Operating systems like iOS and Android also have settings for encrypted DNS. In many cases, the default is set by the browser or OS vendor, not the user or the network administrator.
Where the Trust Lands
Encrypted DNS is a genuine improvement over the plaintext status quo. It closes a long-standing vulnerability and raises the cost of mass surveillance. But it does not eliminate the need for trust. It moves that trust from the local network and the ISP to the resolver operator, the browser vendor, and the device manufacturer. Each of these actors has its own incentives, its own jurisdiction, and its own accountability mechanisms.
For the protocol politics community, this is a case study in how technical design choices distribute power. The decision to use DoH over DoT, the choice of default resolver, the handling of logs—these are not just engineering details. They are governance decisions made by protocol designers, implementers, and deployers. Understanding them requires looking past the encryption and asking: who holds the keys, and under what rules?
This article is part of a series on DNS governance. A future piece will examine the role of browser vendors as de facto policy enforcers in the encrypted DNS ecosystem.