Sovereign DNS Resolver: Jurisdictional Control for Regulated Organisations

A sovereign DNS resolver is a recursive Domain Name System resolver that operates entirely within a defined legal jurisdiction, under the control of the organisation or a trusted European operator, with no query metadata flowing to foreign-controlled infrastructure. For regulated organisations in the EU, the choice of DNS resolver is not merely a network engineering preference: it determines which legal systems can compel access to your users’ browsing and communication metadata, and whether that metadata can be used as an attack vector or forensic trail by adversaries.

The Jurisdictional Problem with Google and Cloudflare DNS

Every DNS query sent to a US-operated resolver is potentially subject to US law, regardless of where the querying organisation is located.

When a hospital’s endpoint resolves intranet.hospital.example against Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1, that query, paired with the source IP address and timestamp, becomes metadata held by a US-headquartered entity. Both Google and Cloudflare are US persons under the Clarifying Lawful Overseas Use of Data (CLOUD) Act of 2018, which allows US law enforcement to compel production of data those companies control regardless of where it is stored. FISA Section 702 adds a parallel channel for intelligence collection that does not require a warrant by European standards and operates without judicial oversight visible to the data subject or their organisation.

The European Data Protection Board has stated that organisations relying on third-party recursive resolvers outside the EU must assess whether that reliance is compatible with their data protection obligations, particularly regarding the transfer of query metadata to non-adequate third countries.

Beyond jurisdiction, public resolvers represent a concentration risk. A single misconfiguration, BGP hijack, or policy change at Cloudflare or Google affects millions of organisations simultaneously. ENISA’s Threat Landscape 2023 report identified DNS manipulation and DNS-based reconnaissance as among the top techniques used in attacks against EU public administration and healthcare sectors.

DNS4EU: The EU’s Sovereign Resolver Initiative

DNS4EU is a concrete, deployable alternative funded under the EU Connecting Europe Facility (CEF Digital) programme, designed from the outset to keep DNS resolution and its associated metadata entirely within European jurisdiction.

The DNS4EU project, operated by a consortium led by Whalebone under European Commission oversight, provides a recursive resolver service with several properties that matter operationally for regulated organisations: all data processing occurs within the EU; the service commits to no transfer of query data to third countries; DNSSEC validation is enabled by default; and threat intelligence filtering (blocking known malicious domains) is built into the resolution path. The European Commission positions DNS4EU explicitly as critical infrastructure for NIS-2 in-scope entities and public sector bodies.

Adoption in practice is straightforward at the network level. An organisation replaces the resolver IP addresses configured in DHCP, Active Directory DNS settings, or firewall DNS proxy rules with the DNS4EU endpoints. For organisations with multiple sites, the same endpoints are applied at each perimeter. Where an organisation needs to maintain internal split-horizon DNS for private domains, DNS4EU can be configured as the upstream forwarder for all external queries while internal authoritative zones remain on-premises. Swiss-hosted sovereign workspaces can apply the same model, pointing their resolver configuration at DNS4EU or a contractually auditable European resolver with equivalent guarantees.

Technical Controls Required Under NIS-2 and ENISA Implementing Regulation (EU) 2024/2690

NIS-2 Article 21 and its implementing act, ENISA Implementing Regulation (EU) 2024/2690, translate the directive’s risk management obligations into concrete technical requirements for DNS. A compliant sovereign DNS stack must address four interlocking controls.

DNSSEC Validation

DNSSEC, defined in IETF RFC 4033 through RFC 4035, establishes a cryptographic chain of trust from the DNS root through each delegation to the authoritative zone. A validating resolver checks that every DNS response carries a valid signature from the zone’s key-signing infrastructure before accepting it. This directly counters DNS cache poisoning (the Kaminsky attack class) and BGP-based response injection. Implementing Regulation (EU) 2024/2690 explicitly requires measures against spoofing and cache poisoning for in-scope entities, and DNSSEC validation at the resolver is the primary technical control for this requirement. Organisations should also ensure that their own authoritative zones are DNSSEC-signed, not only that their resolvers validate incoming responses.

Encrypted Transport: DoT and DoH

DNS over TLS (DoT), specified in RFC 7858, and DNS over HTTPS (DoH), specified in RFC 8484, both encrypt the DNS query and response between the client and the resolver, preventing on-path eavesdropping and manipulation. DoT operates on TCP port 853 and is typically used for resolver-to-resolver or endpoint-to-internal-resolver communications. DoH wraps DNS in HTTPS on port 443, making it indistinguishable from ordinary web traffic to passive observers.

The Implementing Regulation requires query confidentiality in transit. Both DoT and DoH satisfy this requirement. The critical operational decision is whether these protocols terminate at the organisation’s own sovereign resolver or bypass it to reach an external service. Only the former preserves both compliance and security monitoring capability.

Response Policy Zones (RPZ)

Response Policy Zones allow a resolver to intercept queries for domains listed in a threat intelligence feed and return a synthesised response (typically NXDOMAIN or a sinkhole IP) instead of the real answer. This mechanism, supported by BIND, Unbound and other open-source resolver stacks, is the primary DNS-layer control for blocking malware callbacks, phishing domains, and command-and-control infrastructure. Europol reported in its 2023 Internet Organised Crime Threat Assessment that DNS-based command-and-control infrastructure was present in the majority of dismantled cybercriminal networks, which makes RPZ-based blocking a directly proportionate and auditable countermeasure. Implementing Regulation (EU) 2024/2690’s malware and phishing mitigation requirements are partially satisfied by a well-maintained RPZ policy.

Resolving the Encrypted DNS versus Security Monitoring Tension

Encrypted DNS creates a genuine operational dilemma: the same encryption that prevents a foreign resolver from logging your users’ queries also prevents your own SIEM from seeing them, unless the architecture is designed correctly.

The answer lies in where encryption terminates. If DoT or DoH terminates at an external resolver, your monitoring tooling is blind. If it terminates at your own sovereign resolver, which then logs all queries to your SIEM before forwarding them (over encrypted channels) to upstream resolvers, you retain full telemetry. The correct architecture therefore combines: (1) internal DoT/DoH endpoints on the sovereign resolver, (2) firewall rules blocking direct DoH connections from endpoints to external IP ranges associated with Google, Cloudflare, or other public resolvers, and (3) SIEM integration that ingests structured DNS query logs from the resolver in real time.

This design gives security teams the DNS metadata they need for threat hunting and incident response while simultaneously preventing that metadata from leaking to foreign-controlled infrastructure. ENISA’s position is unambiguous: “The security of DNS is a prerequisite for the security of the entire internet. Without trustworthy name resolution, no other layer of the stack can be fully trusted.”

Migration Without Outages: Procurement and Operational Steps

Moving from a hyperscaler or ISP-provided resolver to a sovereign stack requires a sequenced approach. The following table maps the migration phases against the main risk areas.

Procurement for Swiss-hosted sovereign resolver capacity should require the provider to confirm: data processing within Switzerland or the EU, contractual prohibition on onward transfer to non-adequate jurisdictions, audit rights and annual penetration test reports, and SLA availability of at least 99.95 percent with geographically redundant nodes. The IBM Cost of a Data Breach Report 2023 places the average breach cost at USD 4.45 million globally, with infrastructure compromise among the costliest categories, making resolver availability a directly quantifiable business continuity variable.

Post-Quantum Cryptography and the Future of DNSSEC

DNSSEC’s current signature algorithms, primarily RSA and ECDSA, will be broken by a Cryptographically Relevant Quantum Computer (CRQC). NIST finalised ML-DSA (FIPS 204) in August 2024 as the post-quantum digital signature standard intended to replace these classical algorithms across all applications, including DNSSEC. The IETF is actively working on registering ML-DSA as a DNSSEC algorithm identifier, but the migration path is long: zone operators, registrars, resolver software, and trust anchor distribution mechanisms all require coordinated updates.

For regulated organisations with data confidentiality horizons extending beyond five to ten years, the “harvest now, decrypt later” threat is already relevant at the DNS layer. An adversary archiving encrypted DNS traffic today can retrospectively analyse it once a CRQC becomes available. Organisations should: inventory all DNSSEC key material and document key rollover procedures; monitor IETF and ENISA publications on post-quantum DNSSEC algorithm timelines; and ensure their sovereign resolver software (Unbound, BIND, Knot Resolver) is on a vendor roadmap that includes ML-DSA support. Swiss-hosted infrastructure, operating under the revised Federal Act on Data Protection (revFADP) and outside CLOUD Act jurisdiction, provides a stable foundation from which to execute this migration without jurisdictional interference during the transition period.

FAQ

Is using Google 8.8.8.8 or Cloudflare 1.1.1.1 a GDPR violation for a regulated EU organisation?

Not automatically, but it creates substantial compliance risk. Both resolvers are operated by US entities subject to the CLOUD Act and FISA 702, meaning query metadata can be compelled by US authorities without EU judicial oversight. Under GDPR Article 44, transferring personal data, including IP addresses paired with DNS query logs, to a third country requires an adequacy decision, Standard Contractual Clauses, or another valid mechanism. Compliance officers should either document a valid legal basis for the transfer or eliminate the dependency on these resolvers.

What is DNS4EU and who can use it?

DNS4EU is a recursive DNS resolver service funded under the EU Connecting Europe Facility (CEF Digital) programme and operated by a consortium led by Whalebone. It is designed to be GDPR-compliant by design, with no data transfers outside the EU, built-in threat filtering, and DNSSEC validation. It targets public sector bodies, critical infrastructure operators, and other NIS-2 in-scope entities. Adoption involves configuring your network’s resolver settings to point to DNS4EU endpoints in place of current public or ISP-provided resolvers.

Does enabling DoH or DoT on endpoints break our SIEM and network monitoring?

It can, if those protocols terminate at an external resolver. The solution is to enforce that all DoH and DoT traffic terminates at your own sovereign resolver, which logs queries centrally and forwards them to your SIEM. This is achieved by combining internal DoT/DoH endpoints on the sovereign stack with firewall rules that block encrypted DNS connections to external resolver addresses. Your monitoring retains full DNS telemetry; foreign resolvers receive none of it.

What does ENISA Implementing Regulation (EU) 2024/2690 specifically require for DNS?

The Implementing Regulation, adopted under NIS-2 Article 21, requires in-scope entities to implement measures against DNS spoofing and cache poisoning (satisfied by DNSSEC validation), to protect query confidentiality in transit (satisfied by DoT or DoH terminating at the internal resolver), and to maintain DNS availability as part of business continuity planning. RPZ-based threat blocking also directly addresses the malware and phishing mitigation requirements in the regulation and provides an auditable record of blocked resolution attempts.

When will DNSSEC need post-quantum algorithm support, and is it urgent now?

NIST finalised ML-DSA (FIPS 204) in 2024 as the replacement for RSA and ECDSA in digital signatures, including DNSSEC. Cryptographically Relevant Quantum Computers are not yet operational, but the migration timeline across zone operators, registrars and resolver software is measured in years. Organisations handling data with confidentiality horizons beyond five to ten years should begin inventorying their DNSSEC key material, tracking IETF algorithm registration progress for ML-DSA in DNSSEC, and confirming that their sovereign resolver software vendor has post-quantum support on its roadmap.