In the early 1990s, a handful of engineers sat in a room and argued about how email should work. They emerged, years later, with a set of protocols that still route the majority of the world’s electronic mail. The process wasn’t fast. It wasn’t pretty. It was, by most accounts, a grinding, multi-year brawl over headers, encodings, and the exact semantics of a bounce message. Yet the result—the Simple Mail Transfer Protocol and its Multipurpose Internet Mail Extensions—has outlasted countless faster, sleeker alternatives. The lesson, one the industry keeps forgetting in its rush to ship, is that the standards which survive are usually the ones that took the longest to fight over.

This isn’t a fluke. It’s baked into how internet infrastructure gets built. When a protocol takes years to lock down, it means the working group has wrestled with edge cases, clashing business models, and the quiet resistance of operators who will simply refuse to deploy something that breaks their existing setups. The final document isn’t just a technical spec; it’s a record of a negotiated settlement between network operators, platform providers, and end-user advocates. The time spent is a rough proxy for the breadth of input and the depth of operational scars considered.

The IETF’s Rough Consensus and the Price of Haste

The Internet Engineering Task Force, the main body for internet protocol standards, runs on the principle of “rough consensus and running code.” The running code part is the kicker: no standard moves forward without at least two independent, interoperable implementations. That requirement alone can tack years onto a process, as implementers discover that what looked clean on a whiteboard crumbles when it hits real network topologies and legacy middleboxes.

Take HTTP/2. The push started in earnest around 2012, building on Google’s SPDY experiment, and the final RFC landed in 2015. Three years might sound quick, but SPDY had been deployed and beaten up since 2009. The working group burned much of its time not on the core multiplexing features, but on hashing out the header compression algorithm—a seemingly dull detail that had deep privacy implications, as later shown by HPACK’s resistance to the CRIME attack. The delay wasn’t bureaucratic sludge; it was the group’s insistence on a design that wouldn’t leak session cookies across compression contexts. That kind of foresight only happens when you give security researchers and protocol designers enough rope to break things.

Compare that to the rush to standardize WebRTC’s early versions. The initial excitement for real-time communication in browsers spawned a mess of draft implementations, but the lack of a finished signaling protocol meant different browser vendors built incompatible session description formats. For years, developers had to maintain separate code paths for Chrome and Firefox, gutting the very interoperability the standard was supposed to provide. The eventual stabilization of the WebRTC spec, capped by the 1.0 release in 2018, was a painful but necessary correction. The takeaway: a standard that ships too early isn’t a standard; it’s a proprietary API with a thin coat of openness.

When Infrastructure Standards Become Economic Battlefields

The slowest standards processes are rarely about technical elegance. They’re about who foots the bill for the infrastructure, who controls the data, and who gets to extract rent. The decade-long slugfest over email authentication—spanning SPF, DKIM, and DMARC—wasn’t a debate about cryptographic algorithms. It was a struggle between large senders who wanted to protect their brand domains, mailbox providers who wanted to cut spam, and mailing list operators who saw their forwarding models shattered by strict SPF policies. Each draft reflected a different power balance, and the final DMARC specification, published in 2015, was less a technical victory than a political armistice.

This pattern repeats up and down the stack. The Multiprotocol Label Switching architecture took nearly a decade to standardize because it threatened the business models of traditional IP routing vendors. The Border Gateway Protocol’s security extensions, RPKI and BGPsec, have been in the works for over fifteen years and still aren’t universally deployed, largely because they require network operators to hand routing autonomy to centralized trust anchors—a trade-off many operators find unacceptable. In each case, the delay isn’t a sign of failure but of genuine, unresolved conflict between stakeholders with legitimate, competing interests.

DNS over HTTPS: A Case Study in Fractured Trust

Maybe no recent protocol debate lays the stakes barer than DNS over HTTPS. What started as a privacy enhancement—encrypting DNS queries to block surveillance and manipulation—quickly blew up into a governance crisis. Traditional DNS operators, including plenty of ISPs and enterprise network admins, saw DoH as a threat to their ability to filter malicious domains and enforce acceptable-use policies. Mozilla’s decision to turn on DoH by default in Firefox, routing queries to Cloudflare, was read as a unilateral restructuring of the internet’s name resolution hierarchy.

The IETF’s DNS over HTTPS working group spent years chewing over the implications, producing RFC 8484 in 2018. But the standard itself didn’t settle the governance questions. It just specified the protocol; the decisions about which resolvers to trust and how to discover them were left to application developers and operating system vendors. The result is a fractured landscape where different browsers and devices make different choices, and where enterprise network operators are still scrambling to adapt. The standard was published relatively fast by IETF clocks—about two years—but the real negotiation is ongoing and will probably drag on for another decade.

The Hidden Costs of Expedited Standards

When standards are rushed, the costs rarely land on the authors. They land on network operators who have to build workarounds, on end users who get degraded service, and on the wider ecosystem that has to swallow the technical debt. The fast-tracked standardization of the WebSocket protocol in 2011, for instance, led to widespread deployment of a framing mechanism that was incompatible with many existing HTTP intermediaries. Proxy operators had to choose between breaking WebSocket connections or upgrading their infrastructure—a cost that never made it into the standardization calculus.

Similarly, the rapid uptake of the Server Name Indication extension for TLS created a privacy vulnerability that took years to patch. SNI sends the destination hostname in cleartext during the TLS handshake, letting network observers profile user behavior even when the subsequent connection is encrypted. The fix, Encrypted SNI, was proposed almost immediately but didn’t get standardized until 2018 as part of TLS 1.3, and even then, deployment has crawled. The original SNI spec was published in 2003, after a relatively short working group process, and its privacy implications were noted but not prioritized. Two decades later, we’re still cleaning up the mess.

These examples point to a structural problem: standardization bodies are incentivized to produce documents, not to guarantee long-term operational sustainability. The engineers who write the specs are often not the same people who will maintain the networks running them. The IETF’s mantra of “rough consensus and running code” is meant to bridge this gap, but when the running code comes from a single dominant vendor, the consensus can be more rough than genuine.

The QUIC Protocol: A Deliberate Exception

QUIC, the transport protocol that underpins HTTP/3, is a notable counterexample. Developed mainly by Google and deployed at scale before standardization, QUIC could have hardened into a proprietary lock-in mechanism. Instead, the IETF’s QUIC working group spent nearly five years redesigning the protocol to separate the transport layer from the application layer, making sure it could carry traffic beyond just HTTP. The process was contentious, with serious pushback from network operators who feared losing visibility into traffic characteristics. The resulting standard, published as RFC 9000 in 2021, reflects a careful balance: it encrypts more of the transport layer to prevent ossification, but it also provides explicit signals for network management that earlier encrypted protocols lacked.

The QUIC working group’s deliberate pace wasn’t a sign of dysfunction. It was a recognition that a protocol designed to replace TCP—the internet’s most fundamental transport mechanism—couldn’t be rushed. The group actively sought input from network operators, middlebox vendors, and enterprise network administrators, folding their feedback into the design. The result is a standard that, while not perfect, has a much higher chance of universal deployability than a proprietary alternative shoved through a faster process.

What Operators Can Learn from the Slowest Standards

For network operators and infrastructure engineers, the history of protocol standardization offers a few practical lessons. First, sustained, unresolved debate in a working group isn’t a red flag; it’s often a sign that the group is grappling with real operational constraints that a faster process would just steamroll over. When a draft cycles through multiple revisions without reaching consensus, it usually means the problem space is genuinely thorny and that premature standardization would produce a spec that works in the lab but falls flat in the field.

Second, the most durable standards are those that explicitly document their own limitations and trade-offs. The BGP specification, for example, is remarkably blunt about its security weaknesses, and that honesty has let operators develop compensating controls over time. Standards that pretend to solve every problem often create new ones by hiding their assumptions. A good standard tells you not just what to implement, but what to watch out for.

Third, operators should be wary of standards that emerge too quickly from a single vendor’s codebase. The history of internet protocols is littered with “standards” that were really just documentation of a dominant implementation, and that became de facto standards only because the market had no alternative. True interoperability requires a specification that multiple parties can implement independently, and that requires time for review, testing, and disagreement.

The Role of the Network Operator in the Standards Process

One of the quiet dysfunctions of the current standards ecosystem is the underrepresentation of network operators in working groups. The IETF’s membership is dominated by vendors and platform companies, with relatively few participants from the enterprises and service providers who will actually deploy the protocols. This imbalance means that operational considerations are often raised late in the process, after significant design decisions have already been locked in, leading to delays and acrimony.

Operators who want to avoid being blindsided by new standards should consider participating directly in the standards process, or at least monitoring working group mailing lists and providing feedback during last-call reviews. The IETF’s processes are open to anyone, and the barrier to entry isn’t technical expertise but the willingness to read drafts and offer constructive comments. A single well-reasoned message from an operator who has actually deployed a protocol at scale can carry more weight than a dozen messages from vendors with theoretical concerns.

FAQ

Why do some internet standards take so long to finalize?

Long standardization timelines are usually a sign that the protocol involves significant operational or economic trade-offs. Working groups must reconcile the interests of network operators, platform providers, and end users, each of whom may have conflicting requirements. The IETF’s requirement for multiple independent implementations also adds time, as implementers discover and resolve ambiguities in the specification. A standard that takes five years to develop is often more durable than one that takes five months, because the longer process surfaces edge cases and deployment challenges that a rushed process would miss.

How can network operators influence the standards process?

Network operators can participate directly in IETF working groups by joining mailing lists, attending meetings, and submitting comments on draft specifications. Even passive monitoring of working group discussions can provide early warning of protocol changes that will affect operational networks. Operators who cannot commit to full participation can still make an impact by responding to last-call reviews with concrete, experience-based feedback. The IETF values operational input, and a single message describing how a proposed standard would break a real network can significantly influence the outcome.

What are the risks of deploying a protocol before it is fully standardized?

Pre-standard deployments can create de facto standards that are difficult to change, even when flaws are discovered later. Early adopters may find themselves locked into a proprietary implementation that diverges from the eventual standard, requiring costly migrations. Additionally, pre-standard protocols often lack the security review and operational guidance that accompany a finalized specification, exposing deployers to unknown risks. The safest approach is to deploy pre-standard protocols only in controlled environments where the cost of change is low, and to plan for a migration path to the standardized version once it is available.

The Long View

The internet’s most critical infrastructure—the protocols that route packets, resolve names, and deliver email—wasn’t built in a hurry. It was built through a process that valued rough consensus over rapid iteration, and that forced designers to confront the messy reality of a network operated by thousands of independent actors with divergent interests. The standards that emerged from this process aren’t elegant. They’re full of compromises, legacy cruft, and design decisions that make sense only in historical context. But they work, and they’ve worked for decades, because they were forged in the fire of genuine, sustained disagreement.

As the internet enters its next phase of evolution, with encrypted transport protocols, decentralized identity systems, and new network architectures, the temptation to accelerate the standards process will be strong. Platform companies will push for faster adoption of their preferred designs. Policymakers will demand quick solutions to pressing problems. But the lesson of the past four decades is clear: the best standards are the ones that took the longest to agree on, because that time was spent building the trust and understanding necessary for a protocol to survive in the wild. Speed is not the enemy of good standards, but it is rarely their friend.

For the operators and engineers who will deploy these next-generation protocols, the advice is simple. Pay attention to the working group debates. Read the dissenting opinions in the RFCs. And when a standard seems to be taking too long, ask yourself whether the delay is a sign of dysfunction or a sign that the working group is doing its job. More often than not, it is the latter.

When the HTTP/2 spec finally landed as RFC 7540 in May 2015, it had been nearly sixteen years since HTTP/1.1. The working group burned over three years arguing about header compression alone. From the outside, that looks like institutional paralysis. If you’ve ever operated a network or kept a service alive at scale, though, that timeline signals something rarer: a standard that actually accounted for who holds power—endpoints, intermediaries, operators. The web standards that stick, that don’t fracture the network, that don’t quietly hand the keys to a single vendor, are almost always the ones that took the longest to agree on. Speed in standards-making correlates with concentrated power. Deliberation correlates with distributed resilience.

This piece walks through three protocol efforts that make the relationship between development pace and power distribution painfully clear: HTTP/2, DNSSEC, and IPv6. Each took well over a decade from initial draft to meaningful deployment. Each got shaped by operational friction, competing economic interests, and the thankless work of preventing unilateral control. Understanding why they took so long matters for anyone who relies on internet infrastructure—which is to say, everyone—but especially for operators, platform architects, and policy-minded engineers who recognize that protocol design is governance by other means.

The Hidden Cost of Fast Standards: How Speed Concentrates Control

Standards that move quickly tend to do so because the design space is narrow and the number of stakeholders is small. That’s not automatically bad—it’s how QUIC got started inside Google before it was brought to the IETF. But when a protocol ships fast and grabs adoption before broader review, the entity that drove the design owns the implementation landscape. Others can implement, but they’re playing catch-up on a field where the first mover has already set the defaults, optimized its own infrastructure, and built a user base that treats the protocol as synonymous with the company’s product.

Look at SPDY, the precursor to HTTP/2. Google built SPDY to solve real performance problems—head-of-line blocking in HTTP/1.1 was making the web slower, and Google’s business depends on a fast web. SPDY was deployed in Chrome and on Google’s servers years before HTTP/2 was standardized. By the time the IETF HTTP Working Group started its work, SPDY was the de facto baseline. The working group didn’t start from scratch; it started from Google’s design, with Google’s implementation experience, and with the quiet understanding that rejecting SPDY entirely would mean fighting Chrome’s market share. The resulting HTTP/2 standard is better for having been debated, but the power asymmetry was baked in from the start. The longer deliberation inside the IETF—especially around header compression, where the working group replaced SPDY’s deflate-based approach with HPACK after demonstrating security vulnerabilities—is what stopped a single vendor’s optimization choices from becoming the internet’s permanent overhead.

What “Slow” Actually Means in Standards Bodies

When engineers complain that the IETF or W3C is “slow,” they’re usually pointing at the gap between having a problem and getting a published RFC. But that gap isn’t empty. It’s filled with interoperability testing, security reviews, and the messy process of discovering that your elegant solution breaks when deployed across networks with different economic incentives. The DNS Security Extensions (DNSSEC) specification took over a decade from initial drafts to deployment not because the cryptography was hard—it wasn’t—but because every design choice had implications for who controls the trust hierarchy. Should the root zone be signed? Who holds the root key? What happens to national ccTLDs that don’t want to participate? These aren’t technical questions you can resolve with a faster hash function. They’re governance questions disguised as protocol parameters.

DNSSEC’s slow path meant that by the time it was deployable, the operational community had a clear understanding of the tradeoffs. Zone operators knew the signing overhead. Resolver operators understood the amplification risks. The root signing ceremony became a public, auditable process rather than a unilateral decision by a single authority. The delay wasn’t a bug; it was the feature that prevented DNSSEC from becoming a mechanism for centralized control of the domain name system.

IPv6: The Thirty-Year Negotiation Over Addressing Power

No protocol illustrates the relationship between development speed and power distribution better than IPv6. The IETF recognized address exhaustion in the early 1990s. The first IPv6 specification was published in 1995. Meaningful deployment didn’t begin until the 2010s, and global adoption only crossed 40% in 2023. This gets described as a failure, routinely. It’s more accurately a thirty-year negotiation over who gets to assign addresses, how routing tables are structured, and whether the internet’s core architecture would remain distributed or consolidate around a few large providers.

The slow transition preserved a critical property: anyone can still get provider-independent address space and route it on the global internet without permission from an incumbent. If IPv6 had been rushed—if the IETF had prioritized deployment speed over architectural integrity—the result would likely have been an internet where only large carriers and content networks could obtain routable addresses. Small operators, enterprises, and new entrants would be forced behind carrier-grade NAT, dependent on the very incumbents the protocol was supposed to circumvent. The delay was the cost of maintaining the internet’s distributed routing architecture.

Network operators who lived through this period understand the tradeoff viscerally. They dealt with dual-stack complexity, with broken IPv6 implementations in consumer equipment, with the operational burden of maintaining two address families. Many still question whether the transition was worth it. But the alternative—a rushed adoption of a protocol that concentrated addressing power—would have fundamentally changed who can participate in internet infrastructure. The slow transition preserved the possibility of a distributed network, even if it didn’t guarantee one.

The NAT Question: A Deliberate Non-Solution

Network Address Translation became the de facto workaround for IPv4 exhaustion, and it’s worth examining why the IETF didn’t simply standardize a more scalable NAT architecture instead of pursuing IPv6. The answer reveals the governance philosophy embedded in protocol design. NAT creates asymmetry: hosts behind a NAT can initiate connections outward, but external hosts cannot easily initiate connections inward. This asymmetry favors large content providers who can afford to maintain publicly reachable endpoints. It disadvantages peer-to-peer applications, self-hosted services, and any architecture that treats endpoints as equals.

The IETF’s refusal to embrace NAT as a permanent solution was a deliberate choice to preserve the end-to-end principle—the idea that the network should not discriminate between endpoints. This wasn’t a technical decision so much as a value judgment about what kind of network the internet should be. A fast, pragmatic solution would have optimized for content delivery and accepted a permanent client-server hierarchy. The slow, principled path preserved the possibility of a more distributed architecture, even if market forces have since pushed much of the internet toward centralization anyway.

WebRTC: When Speed Creates Fragmentation

Not all slow standards succeed, and not all fast standards fail. But WebRTC offers a cautionary example of what happens when standardization can’t keep pace with deployment. Google released WebRTC as an open-source project in 2011, and browsers shipped implementations before the IETF and W3C had finished the specifications. The result was a real-time communications framework that worked brilliantly within Chrome but created interoperability nightmares across browsers, codecs, and signaling protocols.

The codec dispute alone consumed years. Google pushed VP8 (and later VP9) as mandatory-to-implement, while others insisted on H.264. The IETF eventually settled on both as mandatory, which satisfied no one and increased implementation complexity. Meanwhile, the signaling layer was left deliberately unspecified—an unusual choice for a communications protocol—because the working group couldn’t reach consensus. This meant that every WebRTC application had to build its own signaling, fragmenting the ecosystem and making cross-service interoperability effectively impossible. The standard shipped fast, but the parts that would have enabled a truly open, interoperable real-time web were the parts that needed the most negotiation—and those were precisely the parts that got deferred or abandoned.

The Governance Layer Hidden in Plain Sight

What distinguishes a standard that successfully distributes power from one that concentrates it isn’t the technical elegance of the solution. It’s the process by which the standard was developed. Standards that emerge from a single organization and are later brought to a standards body for ratification tend to encode that organization’s assumptions and economic interests. Standards that are developed in the open, with participation from multiple stakeholders who have conflicting incentives, tend to produce more balanced outcomes—but they take much longer.

The IETF’s culture of “rough consensus and running code” is often misunderstood. The “running code” part doesn’t mean shipping first and standardizing later. It means that proposals should be backed by implementation experience to prove they work, but the consensus process still requires working through objections from operators, competing vendors, and other affected parties. This is slow by design. When a working group skips the consensus part and just ships—as happened with aspects of WebRTC—the result is a standard that works for the dominant implementer but creates friction for everyone else.

DNS-over-HTTPS: A Case Study in Process Failure

DNS-over-HTTPS (DoH) represents a recent example where the standardization process moved relatively quickly but the governance implications were not adequately addressed. DoH encrypts DNS queries inside HTTPS connections, which improves privacy by preventing on-path observers from seeing which domains a user is resolving. But it also shifts DNS resolution from the operating system—where it can be managed by network administrators, enterprise security policies, and parental controls—to the browser, where it defaults to a small set of public resolvers operated by companies like Cloudflare and Google.

The technical specification was sound. The governance model was not. By the time network operators and enterprise administrators understood the implications, browsers had already shipped DoH enabled by default. The IETF working group had focused on the protocol mechanics—message format, transport, security properties—but had not adequately addressed the operational and policy questions: Who controls the resolver? What happens to split-horizon DNS? How do enterprise security controls interact with browser-enforced resolution? These questions were left to implementation decisions, which meant they were effectively decided by the browser vendors. The standard was fast. The power concentration was predictable.

What Slow Standards Actually Protect

When a protocol takes years to standardize, it’s usually because the working group is wrestling with questions that aren’t purely technical. These questions include: Who bears the operational cost of deployment? Who controls the trust anchors? What happens to existing infrastructure? Can a new entrant implement the standard without permission from incumbents? Does the protocol create new gatekeepers or eliminate existing ones?

The Border Gateway Protocol (BGP) has been extended and refined over decades, and it remains the routing protocol of the internet not because it’s elegant—it isn’t—but because its slow evolution has preserved the distributed control that defines internet routing. Every autonomous system can set its own routing policies. No single entity controls the routing table. Attempts to replace BGP with something cleaner and more centralized have repeatedly failed, not because the engineering was bad, but because operators recognized that a clean-slate routing protocol would inevitably concentrate control in the hands of whoever designed and deployed it first.

This is the pattern that repeats across successful internet standards: the ones that preserve distributed control are the ones that took long enough for the power dynamics to become visible and contestable. The ones that concentrated power—whether intentionally or not—tended to move faster, because fewer stakeholders had to agree.

What Operators Should Watch For

For those who run networks, build on platforms, or make procurement decisions that depend on protocol stability, there are practical signals that a standard is likely to distribute power rather than concentrate it:

Multi-vendor implementation before ratification. If only one organization has working code when the standard is published, that organization owns the deployment timeline and the de facto interpretation of ambiguous parts of the spec. HTTP/2 had multiple implementations before RFC publication. WebRTC did not.

Operational community engagement. Standards that are developed primarily by protocol designers without sustained input from the people who will operate them tend to create operational surprises. The IETF’s DNSOP working group exists precisely to catch these issues, but it can only do so if given time.

Explicit discussion of incentives. A standard that doesn’t acknowledge who benefits from its adoption and who bears the costs is hiding something. The best working group discussions surface these tensions explicitly rather than pretending they don’t exist.

Deployability analysis. The IETF requires a “deployability considerations” section in many working group documents, but the quality varies enormously. A substantive analysis that addresses migration paths, backward compatibility, and operational impact is a sign that the working group took governance seriously.

What This Means for the Next Generation of Standards

The internet’s protocol stack is not static. New proposals emerge regularly: MASQUE for proxying, OHTTP for oblivious HTTP, various privacy-enhancing extensions to DNS and TLS. Each of these will either distribute power or concentrate it, and the speed of standardization is a leading indicator of which outcome to expect.

This doesn’t mean that all slow standards are good or that all fast standards are bad. It means that speed is a signal worth paying attention to. When a standard moves from proposal to deployment in under two years, ask who benefits from that speed. When a standard takes a decade, ask what power struggles were being negotiated during that time. The answers will tell you more about the future of the internet than any technical analysis of the protocol itself.

The next time someone complains that the IETF is too slow, consider what they’re really saying. They’re saying that the process of negotiating power among network operators, platform providers, and end users should be faster. But power negotiations that happen too quickly tend to produce winners and losers, not equilibria. The internet’s distributed architecture is an accident of history and a product of deliberate, painstaking, often maddeningly slow consensus-building. Preserving it requires the same.

Frequently Asked Questions

Why do some web standards take so long to finalize?

Long standardization timelines typically reflect the complexity of negotiating competing interests among network operators, browser vendors, content providers, and end users. When a standard affects who controls infrastructure, who bears operational costs, or who can participate in the network, the working group must resolve these governance questions before publishing. The technical specification is often the easy part; the power dynamics are what consume years of debate.

Does a slow standardization process guarantee a better outcome?

No. Some standards take a long time because of deadlock, not deliberation. The key distinction is whether the delay is spent resolving substantive disagreements about power and control, or whether it’s procedural obstruction. Standards that emerge from genuine multi-stakeholder negotiation tend to be more resilient, but speed alone is not a guarantee of quality—it’s a signal that warrants closer examination of the process.

How can network operators influence protocol development?

Operators can participate directly in IETF working groups, either by attending meetings or contributing to mailing lists. More practically, they can join operator-focused groups like NANOG or RIPE that provide feedback to standards bodies. The most effective influence comes from sharing operational experience—what breaks in real deployments, what creates management burden, what shifts control away from operators—rather than advocating for specific technical solutions.

What should I look for when evaluating a new protocol standard?

Examine who implemented it first, who controls the default configuration, whether migration from existing protocols is addressed, and whether the standard creates new dependencies on specific organizations. A standard that can be implemented independently by multiple parties without permission from a central authority is more likely to distribute power than one that requires coordination through a single provider or platform.

In the early 1990s, a small knot of engineers sat in a forgettable conference room, arguing about email. The question on the table sounded almost trivial: should the protocol allow attachments? The Multipurpose Internet Mail Extensions (MIME) specification, which eventually let us send images, audio, and formatted text, took more than five years to lock down. That wasn’t because the problem was technically unsolvable. The delay was the point. The Internet Engineering Task Force (IETF) and its peers have long grasped that the protocols running the internet’s plumbing—routing, addressing, transport—are not neutral engineering artifacts. They are governance instruments. Every header field, every default setting, every extension point encodes a decision about who gets to control what. When a standard is rushed, the distribution of power it hard-codes tends to favor whoever shouted loudest in the room, and that is rarely the most representative voice. The standards that took forever to agree on, by contrast, often became the bedrock precisely because they survived a gauntlet of objections from operators, implementers, and users who knew that technical choices are political choices by another name.

The Hidden Governance of Consensus Timelines

When people talk about internet governance, they usually point to institutions like ICANN or the ITU. But the real action often happens earlier, in the IETF’s working groups, where a protocol’s defaults are fought over line by line. The length of those fights isn’t a sign of bureaucratic bloat; it’s a sign that the participants understand what’s at stake. A protocol that takes years to finalize—think BGP, DNS, or TCP itself—has been hammered against the objections of incumbent network operators, equipment vendors, and the end users who will never read the RFC but will live with its consequences for decades.

Consider IPv6. The address exhaustion problem was obvious by the early 1990s. A naive observer might have expected a quick technical fix. Instead, the standardization dragged on for years, tangled in competing proposals, bitter arguments over header formats, and a transition mechanism debate that still isn’t fully settled. The delay frustrated early adopters, but it also prevented a rushed design that might have baked in even deeper asymmetries. The final protocol, with its vast address space and simplified header, reflects a balance between the largest transit providers and the smallest edge networks. That balance took time to find.

MIME and the Attachment Wars

MIME’s story is worth retelling because it was never just about attachments. It was about who gets to define what a message is. Before MIME, email was plain ASCII text. That limitation wasn’t an accident; it was a control point. It kept email simple enough that anyone could write a client, but it also kept email impoverished. When the push for rich content arrived, it threatened to splinter the ecosystem into proprietary silos—Lotus Notes, Microsoft Mail, and others each had their own scheme. The IETF’s multi-year slog produced a standard that preserved interoperability while opening the door to rich content. The linchpin was the content-type header, a tiny piece of metadata that let senders declare what they were sending and receivers decide how to handle it. That header is a governance tool. It shifts power to recipients, letting them reject or render content according to their own policies, not the sender’s. It took years to get right because every constituency had to be convinced the balance was tolerable.

DNSSEC: A Cautionary Tale of Urgency

If MIME is a success story, DNSSEC is a cautionary tale about what happens when urgency drives the timeline instead of consensus. The Domain Name System Security Extensions were supposed to add cryptographic authentication to DNS responses, blocking cache poisoning attacks. The need was genuine, and the initial specs came together fairly quickly in the late 1990s. But the operational community pushed back hard. DNSSEC demanded changes to the DNS delegation model that many registrars and TLD operators found onerous. The split between key-signing keys and zone-signing keys, meant to simplify key rollover, instead created an operational tangle that few were ready to manage. Deployment stalled for more than a decade. The standard was technically sound but politically tone-deaf. It didn’t account for the incentives of the people who would have to implement it. The lesson isn’t that DNSSEC was a bad idea. It’s that the standard’s relatively quick development—compared to, say, BGP—skipped the slow, bruising negotiation phase that might have produced a more deployable design. The IETF later had to retrofit operational guidance through RFCs like 6781, essentially doing the consensus work after the fact.

BGP: The Protocol That Refuses to Be Replaced

The Border Gateway Protocol is the internet’s routing backbone, and it’s also a monument to the virtues of slow evolution. BGP-4 was standardized in 1994, but its roots stretch back to the late 1980s, and its development was marked by fierce debate between the operators of large transit networks and the growing number of multihomed stub networks. The result was a path-vector protocol that gives each autonomous system significant autonomy over its own routing policies. That autonomy is both a strength and a weakness. It enables the internet’s decentralized structure, but it also enables route leaks and hijacks. Numerous attempts to replace BGP with something more secure have failed, not because the alternatives were technically inferior, but because they couldn’t replicate the political settlement that BGP represents. Network operators are loath to cede the policy control that BGP gives them. Any replacement would have to navigate the same power dynamics that BGP’s original designers spent years negotiating. The slow pace of BGP’s initial development embedded a set of power relationships that have proven remarkably sticky.

HTTP/2 and the Speed Trap

Not all slow standards succeed, and not all fast ones fail. But the HTTP/2 process offers a useful contrast. The IETF’s HTTP Working Group began work on HTTP/2 in 2012, using Google’s SPDY protocol as a starting point. The standardization took about three years, which is relatively fast by IETF standards. The result was a protocol that significantly improved web performance, but it also deepened the web’s dependence on encryption and centralized infrastructure. HTTP/2’s multiplexing features work best when all resources come from a single origin, which incentivizes the use of content delivery networks and reverse proxies. The protocol’s design choices, made under pressure to improve speed, had the side effect of consolidating control over web traffic into fewer hands. The subsequent development of HTTP/3 and QUIC has only accelerated this trend, moving more of the transport layer into user-space and under the control of large platform operators. The speed of standardization, driven by the urgency of performance improvements, may have come at the cost of a more distributed architecture.

The Political Economy of Consensus

Why do some standards take so long? The answer lies in the IETF’s own mantra: “rough consensus and running code.” The “rough consensus” part is often misunderstood. It doesn’t mean a simple majority vote. It means the working group has addressed all serious objections and the remaining dissent isn’t strong enough to derail the process. That’s a high bar, and it gives significant power to anyone who can articulate a well-reasoned objection. In practice, this means large network operators, equipment vendors, and platform providers can slow down a standard that threatens their interests. But it also means smaller players, if they’re persistent and technically credible, can force changes that protect their position. The process is adversarial by design, and the timeline is a function of how deeply the standard cuts into existing power structures.

This isn’t a flaw. It’s a recognition that internet protocols are not neutral. They allocate costs and benefits, they create gatekeepers, and they determine who can innovate without permission. A standard agreed upon too quickly is likely to have overlooked some of these distributional effects. The IETF’s culture of “humming” rather than voting, its insistence on multiple interoperable implementations before advancement, and its tradition of marathon working group sessions are all mechanisms for surfacing hidden power dynamics. They slow things down, but they also make the final product more legitimate.

When Speed Wins and Quality Loses

There are counterexamples, of course. The WebRTC standard, which enables real-time communication in browsers, was developed relatively quickly and has been widely adopted. But WebRTC benefited from a clear, limited scope and a pre-existing consensus among browser vendors about the need for open real-time communication. More often, rushed standards create problems that take years to fix. The early versions of the Simple Network Management Protocol (SNMP) were designed and deployed rapidly, but their security model was so weak that they became a persistent vulnerability for network infrastructure. The fix, SNMPv3, took over a decade to gain traction, and even today, many devices ship with SNMPv1 or v2c enabled by default. The initial speed of standardization created a legacy of insecurity that the industry is still paying for.

What This Means for Infrastructure Governance

The relationship between standardization timelines and power distribution has practical implications for anyone involved in network operations or internet policy. First, it suggests that patience is not just a virtue but a strategic necessity. When a new protocol is proposed, the instinct to push for rapid adoption should be tempered by a careful analysis of who benefits from the default settings. Second, it highlights the importance of participation. The IETF is open to anyone, but effective participation requires technical expertise and sustained engagement. Organizations that fail to invest in the standards process cede influence to those that do. Third, it underscores the need for post-standardization monitoring. Even well-designed protocols can be implemented in ways that undermine their original intent, and the real-world effects of a standard often become visible only after deployment.

FAQ

Why do some internet standards take so long to finalize?

The IETF’s consensus process requires addressing serious objections from all participants, not just a majority. This means that standards affecting power dynamics—like routing, addressing, or content handling—often face prolonged debate as different stakeholders negotiate the distribution of control. The resulting timeline reflects the complexity of balancing competing interests rather than technical difficulty alone.

Does a longer standardization process always produce a better protocol?

Not necessarily. Some protocols, like early versions of SNMP, were standardized quickly and later required significant fixes. However, for core infrastructure protocols where the stakes are high—such as BGP or MIME—the extended timeline allowed for thorough stress-testing against operational realities and diverse stakeholder requirements, leading to more resilient and widely adopted standards.

How can network operators influence the standards process?

Network operators can participate directly in IETF working groups, submit Internet-Drafts, and provide feedback during last-call reviews. The most effective influence comes from sustained engagement, operational experience, and technically sound arguments. Even small operators can shape outcomes if they identify specific harms or deployment challenges that a proposed standard would create.

What are the risks of standards developed outside traditional bodies?

Proprietary protocols or those developed in closed industry consortia often lack the broad legitimacy and interoperability focus of IETF standards. They may embed control points that favor specific vendors or platforms, and they typically do not undergo the same rigorous, multi-stakeholder review. The result can be fragmentation, vendor lock-in, and reduced long-term flexibility for network operators and end users.

The next time you hear complaints about the IETF’s glacial pace, consider what’s actually happening in those working groups. The delays aren’t just about bikeshedding or perfectionism. They’re a form of governance, a way of ensuring that the protocols that underpin the internet don’t quietly encode the interests of the powerful at the expense of everyone else. The best standards are the ones that took so long to agree on that everyone forgot there was ever an alternative.

We like to think of technical standards as quiet, neutral infrastructure—just the plumbing that makes the internet work. But every standard, from BGP to HTTP/3, is a record of choices. Choices about who gets to control traffic, who shoulders the operational costs, and whose interests get baked into the defaults. When a new protocol drops and the applause starts, it’s worth pausing to ask: who was in the room, and what were they optimizing for? For network operators, end users, and platform providers, the answers shape who holds power in ways that are easy to overlook but hard to undo.

Look around the landscape and you’ll see the fingerprints of these decisions everywhere—in the way DNS resolution has quietly migrated toward a handful of global resolvers, in how congestion control algorithms favor content-rich giants, in the assumptions about bandwidth and latency that leave community networks and rural ISPs scrambling for workarounds. The organizations that write the rules—the IETF, W3C, 3GPP—each have their own governance quirks, funding models, and dominant players. Knowing who sits at the table isn’t a parlor game; it’s a way to understand why your traffic takes the path it does, why some encryption models win out, and why the network sometimes feels like it was built for someone else.

The Room Where It Happens

Standards bodies aren’t some meritocratic ideal. They’re arenas where competing economic interests hash out technical specs that will, in turn, reshape markets. The IETF likes to talk about rough consensus and running code, but look at who actually shows up. Participation leans heavily toward engineers from big equipment vendors, content delivery networks, and hyperscale cloud providers. A 2021 Internet Society study found that over 60% of IETF participants came from just 20 organizations—mostly large corporations. That’s not a conspiracy; it’s a simple matter of who can afford to send engineers to three meetings a year and pay them to write drafts in between.

The result is a set of standards that mirror the operational realities of the people in the room. Take Multipath TCP (MPTCP). It was built with assumptions about middlebox behavior that made perfect sense for large content providers but created real deployment headaches for smaller network operators. The standard wasn’t malicious. It was just written by folks whose primary experience of the network was from the data center outward, not from the last mile inward.

Case Study: The QUIC Working Group

QUIC, the transport protocol that underpins HTTP/3, often gets held up as a triumph of internet engineering. And it does some clever things: it cuts latency, improves multiplexing, and encrypts transport-layer metadata that TCP left hanging out in the open. But the working group that produced it was dominated by Google employees in its early, formative years. Google had already rolled out its own version of QUIC across its services and Chrome before the IETF process even kicked off. The standard that emerged wasn’t a clean-slate design; it was a negotiation between Google’s existing implementation and the concerns of other large players—middlebox vendors and mobile network operators, mostly.

This isn’t a knock on the engineers involved. Plenty of them worked hard to accommodate different viewpoints. But the starting point matters. When a single organization deploys a protocol at scale before standardization, the standard becomes a process of ratifying—with some modifications—what that organization already built. The operational complexity of running a global anycast network gets plenty of attention. The operational complexity of managing a rural ISP with a pile of legacy CPE? Not so much.

Who Pays for the Defaults?

Protocol defaults aren’t just technical knobs; they’re economic levers. Consider the evolution of DNS. The original design assumed a hierarchical, fairly static namespace managed by a small set of trusted operators. As DNS became a vector for censorship, surveillance, and commercial data collection, new standards popped up: DNS over HTTPS (DoH), DNS over TLS (DoT), DNS over QUIC (DoQ). Each one tackled real privacy problems. But each one also shifted control over DNS resolution toward the application layer and, in practice, toward a handful of resolvers run by Google, Cloudflare, and a few others.

For a network operator running a local resolver to serve a community or enterprise, DoH can be a real pain. It bypasses local policy, makes troubleshooting a nightmare, and centralizes visibility into user behavior. The privacy benefits are genuine, but so is the power shift. The standard was written mostly by people who saw ISPs as adversaries, not as infrastructure partners. The result is a protocol that treats network-level DNS as a problem to route around, not a function to improve.

The Middlebox Conundrum

Middleboxes—firewalls, NATs, load balancers, deep packet inspection devices—often get cast as the villains of internet innovation. The IETF’s historical stance, laid out in RFC 1958, was that “the network is a simple, dumb, minimal packet transport.” Middleboxes spit in the face of that principle. But they exist because network operators have legitimate needs: security, address conservation, traffic management, regulatory compliance. When standards are written by those who control endpoints, middlebox concerns get treated as obstacles to engineer around, not as requirements to meet.

This sets up a vicious cycle. A new protocol ignores middleboxes. Middleboxes break the protocol. The protocol adds workarounds to evade middleboxes. Middlebox vendors adapt. The result is a more complex, more brittle network where only the biggest players can afford to keep up. The standard, by refusing to engage with the operational reality of middleboxes, ends up reinforcing the dominance of those who can deploy end-to-end solutions at scale.

The Governance Gap

Standards bodies have governance structures, but they weren’t designed to balance power. The IETF runs on open participation and rough consensus, which sounds democratic but in practice favors those with the time, expertise, and travel budgets to show up. The W3C has a more formal membership model, with fees ranging from $2,250 to $77,000 a year depending on organization size and location. The 3GPP is a consortium of national standards organizations, where influence is mediated by membership tiers and the ability to contribute to multiple working groups at once.

None of these models is inherently illegitimate. But they all produce standards that embed the priorities of their most active participants. When a standard gets praised for its technical elegance, it’s fair to ask: elegant for whom? A protocol that shaves milliseconds off a streaming video platform might add jitter to a VoIP call. A security mechanism that shields user data from passive surveillance might make it harder for a network operator to spot a DDoS attack. These aren’t bugs; they’re features, chosen by the people who wrote the spec.

The Transparency Problem

One of the stickiest challenges in standards governance is the lack of transparency around participation and influence. Meeting minutes often get published, but they rarely capture the informal conversations, the hallway huddles, or the design decisions made in corporate labs before a draft ever sees the light of day. The IETF’s “Note Well” reminds participants of their responsibilities, but it doesn’t require disclosure of commercial interests. An engineer from a large CDN can push for a protocol change without ever spelling out how it benefits their employer’s market position.

This isn’t a call for conspiracy theories. Most standards participants are acting in good faith, trying to solve real technical problems. But their definition of the problem is shaped by their employer’s architecture, customer base, and business model. When those perspectives dominate a working group, the resulting standard reflects a particular view of the internet—one where the network core is dumb, the edge is smart, and the user is a consumer of services rather than a peer on the network.

What Gets Left Out

When standards are written by a narrow set of participants, certain use cases get systematically short shrift. Community networks, municipal broadband, research and education networks, and operators in the Global South often lack the resources to participate in standards bodies. Their requirements—affordable backhaul, resilience under constrained power, operation by non-specialist staff—rarely show up in protocol design discussions.

The result is a stack of protocols that assumes always-on connectivity, abundant bandwidth, and a clean split between producers and consumers of content. For a community network in rural India that uses Wi-Fi long-range links and solar-powered relays, those assumptions don’t hold. The network is intermittently connected, bandwidth is scarce, and every node is both a producer and a consumer. Standards written for data centers and CDNs don’t serve these networks well, but they become the default because no alternative is standardized.

The Cost of Ossification

Protocol ossification—the tendency of deployed protocols to become resistant to change—often gets blamed on middleboxes. But ossification is also a product of who writes the standards. When a protocol is designed by a small group of large players, it tends to be optimized for their use cases. Once deployed, it becomes difficult to change because the installed base is enormous and the costs of change fall disproportionately on smaller operators. The large players who drove the original design can adapt; everyone else is stuck with the consequences.

This dynamic is visible in the slow adoption of IPv6. The standard was written by a relatively broad community, but the transition mechanisms were shaped by the operational realities of large ISPs and content providers. Smaller operators, who couldn’t afford dual-stack deployments or carrier-grade NAT, were left with few good options. The standard wasn’t malicious, but it was written by people who could afford the transition costs and who assumed others could too.

What Would Better Look Like?

Improving the representativeness of standards processes isn’t straightforward. Simply adding more participants from underrepresented groups doesn’t guarantee better outcomes if the process itself is structured around the needs of incumbents. Some proposals include funding travel and time for participants from smaller organizations, requiring disclosure of commercial interests in draft submissions, and creating formal mechanisms for incorporating operational feedback from diverse network environments.

There are precedents. The Internet Research Task Force (IRTF) has a more exploratory mandate and has produced work on congestion control and routing that considers a wider range of network conditions. The Global Network Initiative has brought together companies, civil society, and academics to address human rights issues in network operations. These models aren’t perfect, but they suggest that broadening participation and making assumptions explicit can lead to more resilient outcomes.

Another approach is to treat standards not as finished products but as hypotheses about how a network should operate, subject to empirical testing in diverse environments. This would require standards bodies to invest in measurement, to collect data on how protocols perform in different network conditions, and to revise standards based on that evidence. It would also require a cultural shift away from celebrating a standard’s adoption as an unqualified success and toward asking who benefited, who was burdened, and what alternatives were foreclosed.

FAQ

Why does it matter who writes internet standards?

Standards define the default behaviors of the internet. They determine how traffic is routed, how congestion is managed, how security is implemented, and how new services can be deployed. When a small set of organizations dominates the standards process, the resulting protocols reflect their operational priorities and economic interests. This can create barriers for smaller network operators, limit user choice, and embed power asymmetries into the infrastructure itself.

Are open standards processes like the IETF’s truly open?

The IETF is open in the sense that anyone can join mailing lists, attend meetings, and submit drafts. But effective participation requires significant time, expertise, and travel funding, which favors employees of large organizations. The IETF’s culture of rough consensus also means that objections can be overridden if a sufficient majority agrees, which can marginalize minority viewpoints. Openness does not guarantee representativeness.

How can network operators influence standards that affect them?

Network operators can participate directly in standards bodies, though this requires resources. They can also contribute to operator-focused groups like NANOG, RIPE, or the IETF’s own Operations and Management Area, which provide feedback on protocol deployability. Engaging early in the standards process, before implementations are widely deployed, is critical. Once a protocol is baked into hardware or software, changing it becomes exponentially harder.

What is an example of a standard that failed to account for operational diversity?

The initial deployment of DNS over HTTPS (DoH) is a clear example. It was designed to protect user privacy from on-path observers, but it centralized DNS resolution among a few large providers and broke local network management practices. Subsequent revisions have added mechanisms for discovery and opt-out, but the initial design reflected the priorities of application developers and content platforms, not network operators or enterprise administrators.

Standards are not neutral. They are the residue of power struggles, compromises, and unexamined assumptions. The next time a new protocol is announced with fanfare, the useful question is not just “What does it do?” but “Who wrote it, what did they optimize for, and who pays for the defaults?”

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.