DNS and the Sovereignty Problem No Sovereign Cloud Can Solve

In April 2026, De Nederlandsche Bank signed a landmark infrastructure contract with Schwarz Digits — the IT division of the company that owns Lidl — choosing a grocery store's cloud over Amazon's with clear eyes and stated purpose. The European Commission followed weeks later with a €213 million sovereign cloud agreement covering four European providers. Germany's state of Schleswig-Holstein has been migrating off Microsoft for years. The International Criminal Court replaced its Microsoft email suite after a US executive order disrupted access to its systems. Across Europe, institutions are voting with their infrastructure budgets: data stored under American jurisdiction is data that can be reached by American authority, and that risk is no longer acceptable.

The analysis driving these decisions is correct. The problem it has solved is real. But it is not the whole problem.

When a user at De Nederlandsche Bank types a web address into a browser, or when an automated system calls an API endpoint hosted on Stackit's sovereign German infrastructure, the first thing that happens has nothing to do with where the data is stored. The device sends a query to translate that human-readable domain name into a numerical address that computers can route to. That query goes to a resolver, which consults authoritative nameservers, which trace their authority back to a root zone — a master directory that lists every top-level domain on the internet and where to find it.

That root zone is maintained by a California nonprofit. It is published daily by a Nasdaq-listed company headquartered in Virginia. The cryptographic keys that authenticate it are locked in hardware vaults in El Segundo, California and Culpeper, Virginia. Every byte of data can be stored under European law, on European soil, by European staff. The address book that tells the internet where to find it is still American.

Europe's cloud sovereignty movement solved for where data lives. It has not yet solved for how the internet finds it. DNS4EU — the EU's own DNS resolver, launched in June 2025 — is a real answer to part of that problem. It is not a complete one. Understanding the difference requires understanding how the address book actually works, who controls it, and why the legal tools Europe has built to resist the CLOUD Act offer no protection at the layer where this dependency lives.

The Address Book, and Who Prints It

The Domain Name System is the internet's directory service. It translates names into addresses — turning dnb.nl or ecb.europa.eu into the numerical IP addresses that routers understand. Every browser request, every email, every encrypted API call between sovereign cloud services begins with a DNS query. Without DNS, the internet has addresses but no names. With broken or manipulated DNS, it has neither.

The system is hierarchical. A device sends a query to a recursive resolver — typically operated by an ISP, a company, or a public provider like Google's 8.8.8.8 or Cloudflare's 1.1.1.1. The resolver, if it doesn't already have the answer cached, works up the chain: it asks a root nameserver which authoritative servers handle the relevant top-level domain, then asks those servers where the specific domain lives. The answer comes back, and the connection proceeds.

At the top of that chain sits the root zone: a file roughly two megabytes in size that lists every top-level domain in existence — .de, .nl, .eu, .com, .gov, and more than a thousand others — along with the nameservers responsible for each. The Internet Assigned Numbers Authority, a function of the Internet Corporation for Assigned Names and Numbers, manages the root zone's contents. Verisign, operating under a Root Zone Maintainer Agreement renewed with ICANN in October 2024 for an additional eight-year term, compiles the file, cryptographically signs it, and publishes it to root server operators at least once per day. If that file is wrong — if an entry is missing, or points somewhere it shouldn't — the relevant corner of the internet becomes unreachable, regardless of how sovereign the infrastructure behind it is.

There are thirteen root server clusters, labeled A through M, distributed across hundreds of physical locations worldwide. The operators of those thirteen clusters are: Verisign, which operates both the A-root and J-root; USC's Information Sciences Institute; Cogent Communications; the University of Maryland; NASA; the Internet Systems Consortium; the US Department of Defense; and the US Army Research Laboratory. Of the thirteen, ten are American institutions. The three non-American operators are Netnod in Sweden, RIPE NCC in the Netherlands, and the WIDE Project in Japan.

ICANN, the organization that governs the root zone's contents, was created in 1998 as a California nonprofit under a Memorandum of Understanding with the US Department of Commerce. In October 2016, the IANA stewardship transition ended the direct government contract: ICANN assumed full control as a private multistakeholder organization, and the US government formally relinquished its role in root zone oversight. The transition was widely celebrated as internet governance achieving independence from national control.

What the transition preserved was ICANN's California jurisdiction. The revised bylaws locked it in explicitly: any change to ICANN's legal home requires a three-quarters board supermajority plus written approval from the Empowered Community, itself incorporated as a California nonprofit association. The 2016 transition made ICANN independent of the US government. It did not make ICANN independent of US law. These are different things. California courts retain jurisdiction. The California Attorney General has formal oversight of California nonprofits — a fact demonstrated concretely in 2019, when the CA AG's intervention prompted ICANN's board to kill a $1.1 billion acquisition of the .org registry. An American state official exercised decisive influence over the governance of a global namespace. Everyone in European internet policy circles noticed.

The Ceremony in the Vault

Four times a year, in a secure facility either in El Segundo, California or Culpeper, Virginia, a group of international security experts assembles for a procedure that is simultaneously one of the internet's most critical technical operations and one of its least-known political facts.

Access requires government-issued identification, biometric scanning, and escort by cleared personnel. Inside a ceremony room — a secure vault environment — participants retrieve smart cards from a safe, activate a Hardware Security Module using those cards in sequence, and use the HSM to perform the Root Zone Key Signing Ceremony. The HSM contains the Root Key Signing Key: the private cryptographic key from which all DNSSEC validation ultimately derives. The KSK never leaves the device. The device has never been connected to the internet.

The purpose of the ceremony is to use the KSK to sign the Zone Signing Keys that Verisign will use to cryptographically authenticate DNS root zone data for the following quarter. Without valid signatures from the KSK, DNSSEC-validating resolvers — which verify that DNS responses haven't been tampered with in transit — cannot confirm the integrity of the root zone. The chain of trust that makes secure DNS possible terminates at this ceremony, in these rooms, with these keys.

Every step is scripted, logged, and audited by two Big Four accounting firms with no affiliation to either ICANN or Verisign. The entire proceeding is livestreamed and recorded, with archives posted publicly. There are exactly fourteen Trusted Community Representatives authorized to participate as Crypto Officers — seven assigned to El Segundo and seven to Culpeper. A minimum of three must attend each ceremony for quorum. If fewer than three can be present, the ceremony is cancelled and rescheduled.

The Root Key Signing Key exists in two places on Earth. Both are in the United States.

In 2018, ICANN conducted the first-ever KSK rollover — retiring the original key generated in 2010 and replacing it with a new one. The operation required more than a year of preparation and coordinated global communication, because every major DNS resolver operator in the world had to update its local copy of the trust anchor before the old key was retired. Those that failed to update in time found their DNSSEC-validating resolvers unable to confirm DNS responses — effectively broken for secure resolution until corrected.

A European institution can build the most sovereign cloud infrastructure available. It can encrypt everything, store it in Germany, staff it entirely with EU nationals, and govern it entirely under EU law. Its ability to participate in authenticated, DNSSEC-validated DNS still traces, every ninety days, to a ceremony in a vault in California or Virginia.

The Incident That Made the Abstract Concrete

On February 28, 2022, three days after Russian forces crossed into Ukraine, Ukrainian Deputy Prime Minister Mykhailo Fedorov wrote to ICANN CEO Göran Marby with three requests. He asked ICANN to revoke Russian country-code top-level domains — .ru, .рф, and .su — from the root zone. He asked ICANN to shut down DNS root servers operating on Russian territory. He asked ICANN to contribute to the revocation of SSL certificates issued within those domains. The argument was that Russia was using internet infrastructure to spread propaganda and disinformation, and that removing Russian domains from the address book would disrupt that machinery.

Fedorov sent a parallel letter to RIPE NCC, the Amsterdam-based Regional Internet Registry for Europe, the Middle East, and Central Asia, requesting revocation of Russian IP address resources.

On March 2, ICANN CEO Göran Marby replied. ICANN declined every request. The language was careful and principled: ICANN "has no sanction-levying authority," its "mission does not extend to taking punitive actions, issuing sanctions, or restricting access against segments of the Internet." Making unilateral changes to the root zone would "erode trust in the multi-stakeholder model and the policies designed to sustain global internet interoperability." RIPE NCC issued a parallel refusal, also citing neutrality.

Both organizations made the right call. Weaponizing the root zone against a nation-state — removing its domains from the global address book as a punitive measure — would have fractured internet governance in ways that may have proved irreversible, and would have established a precedent that any sufficiently motivated government could leverage for any sufficiently defined cause. The refusals were correct.

But the episode exposed the underlying power structure with the clarity of a focused lens. A government made requests affecting global internet infrastructure. A California nonprofit decided whether to comply. The decisions were independent, principled, and right. They were also made in El Segundo and Los Angeles, not in Brussels or The Hague. Every government in Europe watched that exchange and drew a map.

The inverse scenario is the one that concentrates European minds. Not whether ICANN would weaponize the root zone against Europe — ICANN's bylaws are specifically designed to resist government pressure, and the organization has demonstrated that independence under real conditions. The question is what pressure looks like when it arrives through channels ICANN's bylaws weren't designed to address: California courts, which retain jurisdiction over a California nonprofit; sustained regulatory attention from American agencies with authority over US entities; or the kind of disruption — not a deliberate act but a cascading legal consequence — that temporarily cost the ICC access to its Microsoft email in February 2025 after a US executive order targeting the court's prosecutor. That wasn't a cyberattack. It wasn't sabotage. It was a private American company, caught between conflicting legal obligations, making a decision that briefly severed a European international institution from its communications infrastructure. Nobody had to touch the root zone. The dependency was already upstream.

Europe's Answer, and Where It Stops

On June 9, 2025, the European Union launched DNS4EU — a free, privacy-focused DNS resolver operated by a thirteen-entity consortium from ten EU member states, led by Czech cybersecurity firm Whalebone and supported by the European Union Agency for Cybersecurity. The service offers five resolution profiles, from a clean unfiltered option to full protective filtering with ad blocking and child safety measures. All queries are processed within EU borders, subject to GDPR, with no data monetization. Real-time threat intelligence is shared across EU national CERTs, so a malicious domain flagged in one member state propagates to resolvers across the Union within minutes.

This is meaningful work. It addresses a genuine and underappreciated vulnerability. Before DNS4EU, most European internet traffic resolved through either Google's 8.8.8.8 or Cloudflare's 1.1.1.1 — both American companies, both handling European query data outside EU legal jurisdiction. Every time a European government agency's computer looked up a domain name, metadata about that lookup traveled to American infrastructure. DNS4EU moves that query layer under EU law, EU operational control, and EU data governance. For the resolver layer — the service that handles the translation request — it is a credible European alternative.

It is not an alternative root.

DNS4EU resolves queries by consulting ICANN's root zone — the same master file, maintained by IANA, published by Verisign, and authenticated every quarter by the KSK held in California and Virginia. When DNS4EU receives a query for a Dutch domain, it follows a chain of authority that begins in Europe and terminates, as it always has, in the United States. The service is European. The source of truth it depends on is not.

RIPE NCC represents the closest thing Europe has to genuine root-layer authority. Headquartered in Amsterdam, genuinely European in governance and operation, it manages the K-root server and controls IP address allocation for the European region. Its 2022 refusals — declining both Ukraine's request to revoke Russian address resources and implicit pressure to take sides — demonstrated real institutional independence. But RIPE's authority covers IP address allocation, not domain names. The root zone is outside its mandate.

The gap in Europe's DNS sovereignty architecture is not a failure of DNS4EU's design. The initiative did what it set out to do, and it did it well. The gap is a structural limit on what a resolver service can achieve. DNS4EU solved the query layer. The root layer — the master list of what exists and who authenticates it — remains where it has been since 1993.

The cloud sovereignty debate has been shaped, correctly, by the CLOUD Act. This 2018 legislation gives American authorities the power to compel US-based companies to produce data they control, regardless of where that data is physically stored. It is the core legal instrument that makes European institutional data vulnerable even when stored on European soil by American-operated infrastructure. Against this threat, Europe has built substantial legal architecture: GDPR Article 48, which refuses to recognize foreign court orders lacking an international agreement basis; the Schrems II ruling, which invalidated the EU-US Privacy Shield on surveillance law grounds; the EU Data Act, which requires providers to actively contest unlawful foreign data demands; customer-controlled encryption, which the European Data Protection Board has identified as the only technical measure that fully insulates data from CLOUD Act exposure.

None of that architecture reaches DNS.

The CLOUD Act has legal process. It requires a warrant, a court, and a company served with legal process that it can contest. It can be slowed by GDPR. It can be complicated by encryption. It leaves a paper trail. Microsoft's chief legal officer in France can testify under oath about what the company would and wouldn't do. There is friction, imperfect and incomplete, but real.

Root zone administration requires no legal process. It requires editing a text file.

There is no warrant model for removing a domain from the root zone. No EU court order can compel ICANN to retain an entry. No GDPR provision applies — the root zone contains no personal data. It contains the map of where everything is. The Data Act's anti-extraterritoriality provisions do not reach it. ICANN's bylaws are designed to resist government pressure, and that protection is genuine. But bylaws are a contractual protection operating within a legal jurisdiction, not a constitutional guarantee operating above one. California courts retain jurisdiction over a California nonprofit. That is not a hypothetical risk. It is the same jurisdictional fact that gave the California Attorney General decisive influence over the .org acquisition in 2019.

This is the structural distinction the sovereign cloud movement has not yet confronted. The problem it solved — the CLOUD Act — required legal resistance, and Europe built legal resistance. This problem requires architectural independence: physical custody of cryptographic keys outside American jurisdiction, operational control of root zone publication by non-American entities, governance structures that cannot be reached by American courts. None of these exist for the root layer. None are on any current European policy agenda.

The countries that have built DNS architectural independence are Russia, China, and Iran. All three constructed national internet infrastructure capable of operating without ICANN's root zone — and all three built comprehensive surveillance and censorship capability in the same operation. Russia's sovereign internet law, enacted in 2019 and operationally tested in regional disconnection exercises throughout 2023 and 2024, gave Roskomnadzor the authority to reroute all domestic internet traffic through government-controlled nodes running a national DNS system that does not depend on El Segundo or Culpeper. The architecture works. It works because Russia built control infrastructure capable of serving as a censorship apparatus at the same time it built the sovereignty layer. The technical capability and the political capability were not separable.

This is the dilemma Europe has not publicly named. Genuine DNS sovereignty requires the ability to operate the root layer independently — which means the ability to control what the root says, which implies a censorship capability that Europe has explicitly designed DNS4EU to avoid. DNS4EU cannot become a censorship tool; it was designed to be a security and privacy tool. But a root zone under European sovereign control is, by definition, a root zone that European authorities could edit. That is precisely the capability that makes it sovereign. Whether democratic institutions can hold that capability without eventually using it for content control is a political question, not a technical one. It is the question that neither Russia's approach nor China's approach can help answer, because both resolved it in the same direction.

What solving the root layer would actually require — a European root zone authority with physical custody of cryptographic keys on European soil, genuine institutional co-ownership of root zone publication outside American corporate structures, ICANN governance reform that distributes the KSK across jurisdictions — is infrastructure policy that does not yet have a name in any European legislative agenda. It is not in Gaia-X. It is not in NIS2. It is not in the EU Data Act. The absence is not an oversight. It is a reflection of how difficult the problem is, and how much harder it becomes once its full shape is acknowledged.

Stackit did not plan to become a hyperscaler. It became one because the Schwarz Group could not responsibly route the data of 595,000 employees and 14,200 stores through American cloud infrastructure subject to foreign legal authority. The infrastructure was built because the dependency became operationally intolerable. European DNS sovereignty may arrive the same way — not as a deliberate architectural choice, but because a geopolitical event makes the existing dependency impossible to sustain. The address book problem will not be solved before that event. The only question is whether Europe has started building the alternative by the time it needs one.

Jonathan Brown (A.A.Sc., B.Sc) writes about cybersecurity infrastructure, privacy systems, the politics of AI development and many other topics at bordercybergroup.com and aetheriumarcana.org. Border Cyber Group maintains a cybersecurity resource portal at borderelliptic.com . He works from a custom-built Linux platform (SableLinux™) which is currently under development and fully documented at https://github.com/black-vajra/sablelinux.

If you would like to support our work, providing useful, well researched and detailed evaluations of current cybersecurity topics at no cost, feel free to buy us a coffee! https://bordercybergroup.com/#/portal/support