Quad9 exits France November 24: update your DNS configs now

Quad9, the privacy-focused DNS resolver, will cease operations for users in France on Tuesday, November 24, 2026. This decision follows a French court order requiring the service to block specific domains associated with sports piracy, a mandate Quad9 refuses to implement. System administrators and homelab owners in France must immediately audit their network configurations to replace Quad9 addresses before services break.

What happened

On October 21, a French court ruled in favor of beIN, a Qatari sports broadcaster, ordering Quad9 to stop resolving domains that host pirated streams for French users. Rather than comply with the censorship requirement, Quad9 announced it would withdraw from the French market entirely. While the court reduced the daily penalty to €1,000, Quad9 cited approximately 20 pending lawsuits as the primary reason for its exit, stating it cannot survive the accumulation of potential fines.

The withdrawal affects a wide range of entities, including major French institutions like EDF, SNCF, and DINUM. It also impacts individual users who recently migrated to Quad9 following Mullvad’s announcement that it is shutting down its public encrypted DNS service on November 2, 2026. Users who followed Mullvad’s advice to switch to Quad9 now face a second migration within weeks. Quad9 warned that IP-based geo-blocking is ineffective because users can bypass it via VPNs, making compliance legally risky without comprehensive filtering.

Key details

• Deadline: Quad9 stops serving French users on November 24, 2026.
• Affected IPs: 9.9.9.9, 149.112.112.112, 2620:fe::fe, 2620:fe::9, and 9.9.9.10 will cease functioning for French connections.
• Legal context: Quad9 faces roughly 20 pending lawsuits related to domain blocking orders in France.
• Mullvad impact: Users migrating from Mullvad DNS (closing November 2) to Quad9 must migrate again shortly after.
• Alternatives: Cloudflare and DNS4EU remain available but comply with French court orders; self-hosted Unbound offers independence but lacks encrypted upstream queries by default.
• Configuration scope: Changes are required in routers, Pi-hole, Unbound, systemd-resolved, Docker, and browser DNS-over-HTTPS settings.

Background

DNS, or Domain Name System, translates human-readable domain names into IP addresses. Most users rely on public resolvers like Quad9, Cloudflare, or Google rather than running their own recursive resolvers. Privacy-focused resolvers like Quad9 gained popularity by promising not to log user data and by resisting censorship requests. However, when a resolver operates within a jurisdiction, it is subject to local laws. In France, recent legal precedents have forced major providers to block access to sites accused of hosting pirated content.

Running a local recursive resolver, such as Unbound, allows an organization to query root servers directly. This approach removes reliance on third-party providers who might be compelled to filter results. However, standard recursive queries are unencrypted, meaning Internet Service Providers can still see which domains are being requested. This trade-off between privacy from the resolver and visibility to the ISP is a key consideration for teams deciding on a replacement strategy.

Why it matters

For teams managing self-hosted infrastructure, hidden DNS dependencies are a common source of sudden outages. A configuration file written years ago may still point to 9.9.9.9, causing internal services or external API calls to fail once the resolver stops responding. Unlike a web server crash, DNS failures can be subtle, leading to slow timeouts rather than immediate errors, making diagnosis difficult during an incident.

This event highlights the risk of relying on single points of failure for critical infrastructure components. Even non-profit organizations with strong privacy stances are vulnerable to legal pressure. Teams that assumed Quad9 was a stable, neutral layer must now recognize that geopolitical and legal factors can disrupt these services unexpectedly. Proactive auditing of DNS settings is essential to maintain operational continuity.

Furthermore, the timing coincides with Mullvad’s exit from the public DNS space, creating a compound migration challenge. Administrators who recently updated their systems to follow best practices for privacy now find those configurations obsolete. This underscores the need for flexible, easily adjustable network configurations rather than hard-coded dependencies on specific third-party providers.

What you can do

• Audit configurations: Run grep commands across /etc, home directories, and Docker compose files to find instances of 9.9.9.9, 149.112.112.112, or quad9.
• Check active resolvers: Use resolvectl status on Linux or check NetworkManager settings to identify currently active DNS servers.
• Update router settings: Log into your gateway or OpenWrt device and replace Quad9 IPs with alternatives like Cloudflare (1.1.1.1) or DNS4EU in the WAN or DHCP settings.
• Reconfigure local resolvers: If using Pi-hole or Unbound, remove forward-zones pointing to Quad9 and set new upstream servers or enable recursive resolution.
• Update browser DoH: Check Firefox and Chrome settings for DNS-over-HTTPS templates and replace custom Quad9 URLs with supported alternatives.
• Verify changes: After updating, flush DNS caches and test resolution for critical domains to ensure connectivity is restored.