Quad9 Leaves France on 24 November: What to Check and Change Now

Quad9, the Swiss non profit resolver at 9.9.9.9, says it will stop serving users in France from 24 November 2026 rather than obey a Paris court order to block 58 piracy domains. If your devices, routers, clusters or cloud networks in France send DNS to Quad9, find every one now and move them to a tested resolver from another operator.

This is not a breach and nothing has been compromised. It is a supplier leaving a market, and the supplier happens to sit underneath almost everything: every web request, every package download, every API call and every certificate check starts with a DNS lookup. Quad9 is also popular precisely because it blocks known malicious domains, so many teams configured it as a security control. When it goes away in France, two things go with it: name resolution for anything that cannot fall back, and the threat blocking those teams were counting on.

This post sets out what Quad9 and the court reporting actually say, what is still unknown about how the cutoff will work, and then walks through finding and changing Quad9 settings on Linux, Windows, macOS, routers, Kubernetes, containers, VPN profiles, browsers, phones and the three large cloud networks. The legal dispute is described neutrally, with each side's position attributed.

What happened

On 22 October 2026 Quad9 published a post titled "Au revoir, France" on its own blog. It says French courts ruled against it the day before, in a case brought by the sports broadcaster beIN, and that it will make its services unavailable to French users from Tuesday 24 November 2026. In Quad9's words, it must make "our cybersecurity protection and general services unavailable to French users."

TorrentFreak, which reported the ruling the same day, identifies the court as the Paris Judicial Court (tribunal judiciaire de Paris) and gives the case reference as RG 26/11882. French outlets JustGeek and Télé Satellite et Numérique report that the underlying blocking order dates from 13 May 2026, targeted sites streaming tennis matches without a licence, and named several public DNS resolvers. JustGeek says the matches were WTA women's tennis and that the domain list grew through updates from 6 to 58 domains.

The 21 October decision was about enforcement. According to TorrentFreak and Télé Satellite, beIN asked for a penalty (an astreinte) of EUR 10,000 per day for each domain still reachable through Quad9, up to EUR 580,000 per day in total. The court set EUR 1,000 per day in total instead, running until the blocking measures end on 14 November. Quad9's post describes this as a reduction from the amount beIN sought and estimates the total at about EUR 24,000, excluding its own legal costs.

Quad9 says it has not blocked any of the domains and will not. It says an appeal is pending, and that about 20 other lawsuits are pending in France against it and other recursive resolver operators, seeking blocks on hundreds of names. TorrentFreak quotes Quad9 saying it "cannot survive the accumulation of penalties" in those other cases. That is the reason the exit date comes after the 14 November end of this particular penalty: the exit is about the cases still to come, not only this one.

French coverage widened on 23 October. Quad9 is the second public resolver to stop serving France over a sports piracy order. OpenDNS did the same in June 2024.

Each side's position

Quad9

Quad9's post and the coverage of it give these reasons, all in Quad9's own framing:

• Neutral infrastructure. Quad9 describes recursive resolution as a neutral, passive service and says it will not alter or lie about DNS answers in ways users do not expect. Its malware blocking is opt in by choice of address, and it argues a court mandated block is different in kind.
• No way to identify French users. Quad9 says it has no sign up, no accounts and no user location database, so it cannot reliably apply a block only to people in France.
• No global blocking. Blocking for everyone would, in Quad9's view, apply a French ruling to users worldwide, which it calls extraterritorial.
• Experience from Germany. Quad9 cites a 2021 to 2023 case brought by Sony Music Entertainment in Germany, in which it says users evaded its geographic blocking with VPNs and it was fined for contempt. It says it eventually won, at a cost of several years and six figure legal expenses. JustGeek adds that the German fine was EUR 10,000 and that Quad9 then extended the block worldwide.
• DNS blocking does not stop piracy. Quad9 argues the content stays on its servers and users simply switch resolvers. TorrentFreak quotes its comparison to holding a newspaper in front of a stadium. Quad9 says enforcement should target hosting providers and infrastructure.
• Free expression. Quad9 says private blocking powers create a risk to free expression, and asks French users to contact their representatives and Arcom, the French audiovisual and digital regulator.

beIN and the court

None of the coverage we read includes a statement from beIN or quotes the court's reasoning directly. What the reporting establishes is beIN's position through its filings: it sought blocking of the 58 domains through public resolvers as well as ISPs, and asked for a penalty of up to EUR 580,000 per day to enforce it. The court granted a penalty, far smaller than requested, consistent with Quad9's own statement that it had not blocked the domains.

TorrentFreak adds context on how the same court has treated others. It reports that earlier in October the court declined beIN's penalty requests against another large resolver operator and several VPN providers because they had blocked at least some of the domains, which the court treated as a reasonable effort. It also reports that a similar Canal+ penalty request against that resolver operator failed in September. JustGeek reports that other resolver operators named in the May order applied the blocks. We did not find primary statements from those operators, so treat that as reported, not confirmed.

The legal basis is not stated in the 2026 coverage we fetched. TorrentFreak's 2024 reporting on the earlier orders cites Article L333-10 of the French Sport Code, which lets rights holders seek blocking of sports piracy sites. Whether the 2026 beIN orders rest on the same article is something we could not confirm.

We are not taking a side. For defenders, the practical point is the same either way: a resolver many organisations use as a security control will stop answering for one country on a known date.

Timeline

No source publishes times of day for these events, so the table is to the day.

Technical details

Quad9's service addresses

These are the addresses Quad9 publishes on its service addresses page. Every one of them is in scope for the France exit as far as we can tell, because Quad9 talks about withdrawing its services, not one address.

Other values from Quad9's FAQ:

• DNS over TLS runs on port 853 with authentication name dns.quad9.net.
• An alternate plain DNS port, 9953, is offered.
• Blocked malicious domains return NXDOMAIN, the same code as a name that does not exist.
• Quad9 points DNSCrypt users to a resolver list at quad9.net/dnscrypt/quad9-resolvers.toml.

When you search for Quad9 usage, search for all of these. A team that switched from 9.9.9.9 to the ECS variant years ago for CDN performance will be missed by a search for 9.9.9.9 alone.

Quad9 built into Windows

Microsoft's documentation for the Windows DNS client lists Quad9 in the default table of known DNS over HTTPS servers, alongside two other large public resolvers. The Quad9 entries Microsoft lists are 9.9.9.9, 149.112.112.112, 2620:fe::fe and 2620:fe::fe:9. Note the last one: Quad9's own page lists 2620:fe::9 as the second recommended IPv6 address, while Microsoft's table shows 2620:fe::fe:9. Search for both forms.

The table matters because Windows only offers the encryption dropdown when a server is on the known list. Organisations that wanted encrypted DNS on Windows were nudged toward the servers already listed, which is one reason Quad9 shows up in Windows fleets.

How the cutoff will work: unknown

This is the most important open question for operators, and no source answers it.

• Quad9's post does not describe the mechanism.
• TorrentFreak reports that Quad9 has not yet decided how to implement the exit and is evaluating options it describes as imperfect.
• JustGeek says blocking by IP address is one possibility and notes VPNs would bypass it.

The behaviour your systems see will depend on that choice. Here is how the plausible options would look to a client, so you can test your failover against each:

We are not saying which one Quad9 will choose. Plan for the worst case, which is timeouts, and make sure your secondary is a different operator.

Why the second Quad9 address is not a backup

Many configurations list 9.9.9.9 and 149.112.112.112 together. Those are two addresses for one service run by one operator. If Quad9 stops serving France, both stop. The same applies to the two IPv6 addresses and to the DoH and DoT names. Your secondary needs to be a different operator, or your own resolver.

Indicators

There are no indicators of compromise. Nothing malicious happened. The values worth alerting on are the service addresses and names above appearing in configuration and in egress traffic from French sites, and rising SERVFAIL, REFUSED or timeout rates for DNS from those sites after 24 November.

Scale

Wikipedia, citing Quad9, says that as of July 2025 the service ran server clusters in 200 locations in 90 countries on six continents. Quad9's post lists French public bodies and large companies among the networks it serves, including DINUM (the French government's digital directorate), France Travail, EDF and SNCF. We have not verified how any of those organisations use Quad9 and are not suggesting any particular impact on them.

Who needs to act

EU organisations outside France should check two edge cases: branch offices, data centres or cloud regions physically in France, and staff who travel to France with laptops or phones that use Quad9 directly. If your VPN or SASE service egresses through French points of presence, your traffic may look French regardless of where your user is.

French overseas territories are another open question. OpenDNS's 2024 notice covered France and certain French territories. Quad9 has not said what its exit covers.

Step by step: find every Quad9 dependency

Run these in order. Each step catches things the others miss.

1. Search your code and configuration repositories

Infrastructure as code, Ansible roles, Helm values, Dockerfiles, VPN templates and router backups often live in Git. One search across all of them finds most configured resolvers.

# Every Quad9 address and hostname, all service variants
PATTERN='9\.9\.9\.(9|10|11)\b|149\.112\.112\.(112|10|11)\b|2620:fe::(fe|9|10|11|fe:9|fe:10|fe:11)\b|dns(10|11)?\.quad9\.net'

grep -rnE "$PATTERN" --exclude-dir=.git --exclude-dir=node_modules .

Expect matches in files like resolved.conf, netplan/*.yaml, daemon.json, docker-compose.yml, Corefile, *.tf, wg0.conf, *.ovpn, *.mobileconfig and router exports. Some matches will be test fixtures or documentation; review each one.

2. Check Linux hosts

# What the resolver is actually using right now
resolvectl status
resolvectl dns

# Static configuration on disk
grep -rnE '9\.9\.9\.|149\.112\.112\.|2620:fe::|quad9' \
  /etc/resolv.conf /etc/systemd/resolved.conf /etc/systemd/resolved.conf.d/ \
  /etc/netplan/ /etc/NetworkManager/ /etc/dnsmasq* /etc/unbound/ /etc/bind/ 2>/dev/null

# NetworkManager connections
nmcli -g IP4.DNS,IP6.DNS device show

Look for FallbackDNS= lines too. The systemd documentation says fallback servers are used only when no other DNS information is known, but that is exactly the situation on a host whose DHCP lease failed, so a Quad9 fallback can still bite.

3. Check Windows endpoints and servers

# Per interface DNS servers
Get-DnsClientServerAddress -AddressFamily IPv4,IPv6 |
  Where-Object { $_.ServerAddresses -match '^9\.9\.9\.|^149\.112\.112\.|^2620:fe::' }

# The DoH known server list, including any custom templates you added
Get-DnsClientDohServerAddress

# Name Resolution Policy Table rules that route namespaces to specific servers
Get-DnsClientNrptPolicy

Also check the Group Policy setting Microsoft documents at Computer Configuration\Policies\Administrative Templates\Network\DNS Client, "Configure DNS over HTTPS (DoH) name resolution". If it is set to Require DoH and the configured servers are Quad9, Microsoft's documentation says name resolution will fail when the servers cannot be used, with no plain text fallback.

4. Check macOS

scutil --dns | grep -E 'nameserver|resolver'
networksetup -listallnetworkservices
networksetup -getdnsservers "Wi-Fi"

# Encrypted DNS profiles pushed by MDM
sudo profiles show -type configuration | grep -iE 'quad9|DNSSettings|ServerURL|ServerName'

5. Check routers and DNS forwarders

On OpenWrt, which many branch offices and small sites use:

uci show network | grep -E "dns|peerdns"
uci show dhcp | grep -E "server|dhcp_option"

On dnsmasq, Unbound and BIND:

grep -nE '^server=' /etc/dnsmasq.conf /etc/dnsmasq.d/* 2>/dev/null
grep -nE 'forward-addr|forward-host' /etc/unbound/unbound.conf /etc/unbound/unbound.conf.d/* 2>/dev/null
grep -nA5 'forwarders' /etc/bind/named.conf.options 2>/dev/null

For consumer and SMB routers without a shell, open the WAN or internet settings page and the DHCP server page. Quad9 can sit in either: as the router's own upstream, or handed directly to clients through DHCP option 6.

6. Check Kubernetes

# The cluster resolver's upstreams
kubectl -n kube-system get configmap coredns -o jsonpath='{.data.Corefile}' | grep -n forward

# Pods that bypass cluster DNS with their own nameservers
kubectl get pods -A -o json | jq -r '
  .items[]
  | select(.spec.dnsPolicy=="None" or .spec.dnsConfig.nameservers != null)
  | "\(.metadata.namespace)/\(.metadata.name)\t\(.spec.dnsConfig.nameservers // [] | join(","))"'

If CoreDNS forwards to /etc/resolv.conf, which is the common default, the upstream is whatever the node uses, so go back to step 2 for the nodes.

7. Check containers

cat /etc/docker/daemon.json 2>/dev/null | jq '.dns'
grep -rnE '^\s*dns:' --include='docker-compose*.yml' --include='compose*.yaml' .
docker ps -q | xargs -r docker inspect --format '{{.Name}} {{.HostConfig.Dns}}'

8. Check cloud networks

AWS: VPC DHCP options sets and Route 53 Resolver forwarding rules.

aws ec2 describe-dhcp-options \
  --query 'DhcpOptions[].{Id:DhcpOptionsId,Cfg:DhcpConfigurations}'

aws route53resolver list-resolver-rules \
  --query 'ResolverRules[?RuleType==`FORWARD`].{Id:Id,Domain:DomainName,Targets:TargetIps}'

Azure: virtual network custom DNS servers.

az network vnet list --query "[].{name:name, rg:resourceGroup, dns:dhcpOptions.dnsServers}" -o table

Google Cloud: DNS server policies with alternative name servers, and forwarding zones.

gcloud dns policies list --format=json | jq '.[] | {name, alternativeNameServerConfig}'
gcloud dns managed-zones list --format="table(name, forwardingConfig.targetNameServers)"

Run these for every region and subscription you operate in France. A cloud resolver in a French region that forwards to Quad9 will see whatever Quad9 does for French source addresses.

9. Check VPN profiles, browsers and phones

# WireGuard and OpenVPN
grep -rnE '^\s*DNS\s*=' /etc/wireguard/ 2>/dev/null
grep -rnE 'dhcp-option DNS' /etc/openvpn/ 2>/dev/null

Browsers can use their own DoH provider independent of the operating system. Check enterprise policies for Firefox's DNSOverHTTPS policy and Chrome's DnsOverHttpsTemplates policy. On Android, the Private DNS setting takes a hostname; look for dns.quad9.net in MDM restrictions. On iOS and macOS, look for DNS settings payloads in configuration profiles.

10. Watch the wire

Configuration searches miss firmware. Traffic does not lie.

# On a French site gateway or span port
sudo tcpdump -ni any 'host 9.9.9.9 or host 149.112.112.112 or host 9.9.9.11 or host 149.112.112.11 or host 9.9.9.10 or host 149.112.112.10'

# Encrypted DNS to Quad9 shows up as port 853 or as TLS to the DoH name
sudo tcpdump -ni any 'port 853 and (host 9.9.9.9 or host 149.112.112.112)'

Firewall and flow logs work better at scale. Filter for destination addresses in the table above on ports 53, 853, 443 and 9953 from French sites, then map source addresses to device owners. Expect cameras, printers, TVs, NAS boxes and appliances in the results.

Once you have the list, record each item with an owner and a change date before 24 November.

Step by step: change it

The examples below use documentation addresses (192.0.2.53, 198.51.100.53, 2001:db8::53) and the placeholder name resolver.example.net. Replace them with the resolver you choose. Use two operators, or your own resolver plus one operator.

systemd-resolved

Create a drop in rather than editing the main file:

# /etc/systemd/resolved.conf.d/10-dns.conf
[Resolve]
DNS=192.0.2.53#resolver.example.net 2001:db8::53#resolver.example.net
FallbackDNS=198.51.100.53#resolver2.example.org
DNSOverTLS=yes
DNSSEC=allow-downgrade
Domains=~.

sudo systemctl restart systemd-resolved
resolvectl status
resolvectl query example.com

The #name suffix sets the TLS server name, as the systemd documentation describes. With DNSOverTLS=yes, the documentation says requests fail if the server lacks DNS over TLS support or a valid certificate, so test before you roll out. opportunistic falls back to plain DNS and is open to downgrade.

If you use netplan, change the nameservers.addresses list in the YAML and run sudo netplan apply. If NetworkManager owns the interface:

nmcli connection modify "Wired connection 1" ipv4.dns "192.0.2.53 198.51.100.53" ipv4.ignore-auto-dns yes
nmcli connection up "Wired connection 1"

Windows

# Set plain DNS servers on one interface
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("192.0.2.53","198.51.100.53")

# Register a DoH template for a server that is not on the built in list
Add-DnsClientDohServerAddress -ServerAddress '192.0.2.53' `
  -DohTemplate 'https://resolver.example.net/dns-query' `
  -AllowFallbackToUdp $False -AutoUpgrade $True

# Confirm
Get-DnsClientServerAddress -InterfaceAlias "Ethernet"
Get-DnsClientDohServerAddress
Resolve-DnsName example.com

The Add-DnsClientDohServerAddress syntax is from Microsoft's DoH documentation. Microsoft warns against requiring DoH on domain joined machines because Active Directory relies on DNS and the Windows DNS Server service does not support DoH. For domain joined fleets, the fix is usually on the domain controllers' forwarders, not the endpoints:

# On each DNS server
Get-DnsServerForwarder
Set-DnsServerForwarder -IPAddress "192.0.2.53","198.51.100.53" -PassThru

Routers

OpenWrt with dnsmasq:

uci -q delete dhcp.@dnsmasq[0].server
uci add_list dhcp.@dnsmasq[0].server='192.0.2.53'
uci add_list dhcp.@dnsmasq[0].server='198.51.100.53'
uci commit dhcp
service dnsmasq restart

# If Quad9 was set as the WAN DNS
uci set network.wan.peerdns='0'
uci -q delete network.wan.dns
uci add_list network.wan.dns='192.0.2.53'
uci commit network
service network reload

If the router hands Quad9 directly to clients through DHCP option 6, clients only pick up the change when their lease renews. Shorten the lease time a few days before you switch, then restore it.

Unbound as a local forwarder with encrypted upstreams:

forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 192.0.2.53@853#resolver.example.net
  forward-addr: 198.51.100.53@853#resolver2.example.org

Kubernetes CoreDNS

kubectl -n kube-system edit configmap coredns

Replace the forward block with two operators and explicit failover:

.:53 {
    errors
    health
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
    }
    forward . tls://192.0.2.53 tls://198.51.100.53 {
        tls_servername resolver.example.net
        policy sequential
        health_check 5s
        max_fails 2
        failover SERVFAIL REFUSED
    }
    cache 30
    prometheus :9153
    loop
    reload
}

The CoreDNS forward plugin documentation describes each option used here: policy sequential tries upstreams in order, health_check probes each upstream, max_fails marks one down after consecutive failed checks, and failover retries the next upstream when a response carries one of the listed codes. One caveat from the same documentation: tls_servername applies to every upstream in the block. If your two upstreams use different TLS names, use the per endpoint form tls://192.0.2.53%resolver.example.net instead, and do not mix the two.

failover SERVFAIL REFUSED is the part that helps if Quad9 chooses to answer REFUSED. It does nothing for timeouts; health checks handle those.

Then check that pods resolve:

kubectl -n kube-system rollout restart deployment coredns
kubectl run dnscheck --rm -it --image=busybox:1.36 --restart=Never -- nslookup example.com

For pods with their own dnsConfig.nameservers, edit the workload manifests and redeploy.

Docker and Compose

{
  "dns": ["192.0.2.53", "198.51.100.53"]
}

Write that to /etc/docker/daemon.json, restart the daemon, and recreate containers. In Compose files, change the dns: list. Images that write their own /etc/resolv.conf at build time need a rebuild.

AWS

DHCP options sets cannot be edited. Create a new one and associate it:

aws ec2 create-dhcp-options \
  --dhcp-configurations "Key=domain-name-servers,Values=AmazonProvidedDNS"

aws ec2 associate-dhcp-options --dhcp-options-id dopt-0123456789abcdef0 --vpc-id vpc-0123456789abcdef0

For Route 53 Resolver forwarding rules that send everything (.) to Quad9 through an outbound endpoint, update the targets:

aws route53resolver update-resolver-rule \
  --resolver-rule-id rslvr-rr-0123456789abcdef0 \
  --config 'TargetIps=[{Ip=192.0.2.53,Port=53},{Ip=198.51.100.53,Port=53}]'

AWS's documentation notes that rules apply only once associated with a VPC, that queries pass through the outbound endpoint named in the rule, and that the default Internet Resolver rule (type Recursive) cannot be deleted. Deleting a forward rule for . therefore returns those VPCs to the built in recursive resolver, which is a valid fallback if you do not need a third party upstream.

Azure

az network vnet update -g my-rg -n my-vnet --dns-servers 192.0.2.53 198.51.100.53

Virtual machines pick up the new servers on DHCP lease renewal or restart.

Google Cloud

gcloud dns policies update my-policy --alternative-name-servers=192.0.2.53,198.51.100.53

VPN profiles

WireGuard [Interface] section and OpenVPN server push lines:

[Interface]
DNS = 192.0.2.53, 198.51.100.53

push "dhcp-option DNS 192.0.2.53"
push "dhcp-option DNS 198.51.100.53"

Redistribute client profiles; WireGuard clients do not receive the change on their own.

IoT and appliances you cannot reconfigure

Some devices ship with Quad9 in firmware. On networks you own, you can redirect plain DNS to your own resolver at the edge. An nftables example for a site gateway:

nft add table ip dnsfix
nft add chain ip dnsfix prerouting '{ type nat hook prerouting priority -100; }'
nft add rule ip dnsfix prerouting ip daddr '{ 9.9.9.9, 149.112.112.112 }' udp dport 53 dnat to 192.0.2.53
nft add rule ip dnsfix prerouting ip daddr '{ 9.9.9.9, 149.112.112.112 }' tcp dport 53 dnat to 192.0.2.53

This only works for plain DNS on networks you control. DNS over TLS and DoH cannot be redirected transparently; the device will see a certificate mismatch and fail. For those, the fix has to come from the vendor. Ask them in writing which resolver their firmware uses and when an update lands.

Choosing what replaces it

Quad9's post does not recommend a replacement. It links to a public list of DNS servers and notes that thousands of other open resolvers exist, while warning they vary in trust and reliability. French coverage names several public resolvers as examples; JustGeek warns that any of them could face similar suits. We are not ranking providers. Here is what to compare instead, especially if Quad9 was part of your security controls.

Common patterns that work:

• Your ISP's resolver for sites where the ISP is contractually accountable. Note that French ISPs already apply court ordered blocks.
• Your own validating recursive resolver (Unbound, BIND or Knot Resolver) at each site or region, optionally fed with threat intelligence through Response Policy Zones. This removes the third party dependency for recursion, though you then own patching.
• A commercial protective DNS service with a contract, support and documented blocking categories.
• Two of the above together, so that no single operator's legal or operational decision takes you offline.

Test the replacement before you switch

# Plain DNS with DNSSEC validation flag
dig @192.0.2.53 example.com +dnssec +multi | grep -E 'flags|status'

# DNS over TLS
kdig -d @192.0.2.53 +tls-ca +tls-host=resolver.example.net example.com

# Certificate presented on 853
openssl s_client -connect 192.0.2.53:853 -servername resolver.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

# DoH
curl -s -H 'accept: application/dns-json' 'https://resolver.example.net/dns-query?name=example.com&type=A'

The DoH JSON query form is not supported by every provider; some accept only the RFC 8484 wire format. Check the provider's documentation.

To confirm a machine is no longer using Quad9 at all, Quad9's FAQ points to on.quad9.net, which shows a yes or no answer in a browser.

Monitoring through 24 November

Do not assume the configuration change caught everything. Add measurements that will tell you on the morning of 24 November.

Synthetic probes from each French site.

#!/usr/bin/env bash
# Run every minute from cron at each French site; ship output to your log pipeline
for s in 192.0.2.53 198.51.100.53 9.9.9.9; do
  out=$(dig @"$s" example.com +time=2 +tries=1 +noall +comments 2>&1)
  status=$(printf '%s' "$out" | grep -oE 'status: [A-Z]+' | cut -d' ' -f2)
  printf '%s server=%s status=%s\n' "$(date -u +%FT%TZ)" "$s" "${status:-TIMEOUT}"
done

Keep the 9.9.9.9 probe in for now. On the day, it tells you which mechanism Quad9 chose, which helps you judge whether anything you missed will fail fast or slowly.

CoreDNS metrics. The forward plugin exposes Prometheus metrics on the prometheus port. Alert on rising response codes other than NOERROR and NXDOMAIN per upstream, and on health check failures.

Egress counters. Count flows to the Quad9 address ranges from French sites daily. The number should fall to zero before 24 November. Whatever remains is your list of things you did not find.

Help desk tags. Ask the service desk to tag tickets about "site not loading" or "no internet" from France after 24 November, and check them against the inventory.

What changed since first reports

• The penalty. Early summaries cited beIN's EUR 580,000 per day figure. The court set EUR 1,000 per day in total, per Quad9 and TorrentFreak.
• The date confusion. Quad9's post mentions both 14 November and 24 November. They are different things: 14 November is when the blocking measures and penalty period end, and 24 November is when Quad9 stops serving France.
• The court. Quad9's post refers only to the French courts. TorrentFreak and French outlets identify the Paris Judicial Court and TorrentFreak gives the case reference.
• The domain count. Quad9's post does not give a number. The figure of 58 comes from TorrentFreak and French outlets, which say the list grew from 6.
• Other resolvers. Some commentary claimed named large resolvers comply with French blocking orders. The court reporting we read supports a narrower point: the court declined penalties against operators that blocked at least some domains. JustGeek reports two other named operators applied the blocks; we found no primary confirmation.

Open questions

• How will Quad9 implement the exit: refused answers, dropped packets or route withdrawal?
• Will it cover French overseas departments and territories?
• Will it apply to all service variants, including the unsecured 9.9.9.10 and the DNSCrypt service? Quad9 refers to its services generally.
• What happens if the appeal succeeds before 24 November? Quad9 has not said whether it would reverse course.
• What will the roughly 20 other pending French cases decide, and will they reach other resolver operators?
• Will French institutions that Quad9 lists among its users publish guidance for staff?

Common mistakes and troubleshooting

Keeping 149.112.112.112 as the backup. Same operator. It will fail at the same moment.

Changing the OS and missing the browser. Browsers with their own DoH provider ignore the OS setting. Check browser policies.

Changing DHCP and expecting instant effect. Clients keep old servers until their lease renews. Shorten leases ahead of the change.

Requiring encrypted DNS on domain joined Windows machines. Microsoft's documentation advises against it. Fix the domain controllers' forwarders instead.

Strict DoT with a wrong server name. systemd-resolved in strict mode fails closed if the certificate does not match the #name. Test with resolvectl query and check the journal with journalctl -u systemd-resolved.

Losing threat blocking without noticing. A plain resolver will resolve known malicious domains that Quad9 would have refused. If Quad9 was a control in your security policy or an audit, update the control and the evidence.

Assuming only France matters. Cloud regions, SASE exits and travelling staff can make traffic look French from elsewhere.

What would have helped

Practices any team can use

Treat your resolver as a supplier. Put it in your vendor register with its jurisdiction, terms and an exit plan. This exit, like the eMudhra CA situation, is a reminder that infrastructure providers can leave for legal or business reasons with weeks of notice.

Never hardcode resolvers in images, firmware or app code. Take them from the platform: DHCP, the cluster resolver, the cloud provider's resolver. Then one change in one place moves everything.

Two operators, not two addresses. Every resolver list should span at least two independent operators, or your own resolver plus one operator.

Keep a resolver inventory. The searches above take hours the first time and minutes if you run them on a schedule.

Separate resolution from threat blocking. If DNS filtering is a security control, document it as one, with an owner, a test and a replacement plan. Then losing a resolver does not silently remove a control.

Monitor DNS by site. Failure rates per site and per upstream catch problems that global averages hide.

Factor legal exposure into infrastructure choices. Where an operator is incorporated, what orders it can receive and how it says it will respond are now part of resilience planning.

Where Safeguard fits

Safeguard is not a DNS service and does not filter DNS. It does not see your resolver traffic and would not have prevented this. The useful parts are on the inventory and change side.

• Finding the hardcoded addresses in code. The Safeguard CLI assistant can search a repository, edit code and configuration, and run commands with your approval. In this migration that means asking it to find every Quad9 address and hostname in an infrastructure repository, change a Corefile, a netplan file or a Terraform DHCP options set, and run the validation commands above. Its /permissions modes run from Ask through Accept edits, Plan and Auto (the default) to Strict. safeguard exec runs a single non interactive turn for CI, so the same search can run on every pull request.
• Recording the supplier and the risk. The compliance and GRC suite, which is GA, includes Vendors and Risks areas. Record Quad9 (and whichever resolver replaces it) as a vendor, log the exit as a risk with an owner and a date, and attach the inventory as evidence. If Quad9 appears as a control in your ISO 27001 or SOC 2 mapping, update that control. Where it does not help: Safeguard does not inventory DNS settings on endpoints, routers, IoT devices or cloud networks, does not monitor DNS traffic and does not provide threat blocking DNS.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases across seven package ecosystems. A resolver operator's legal decision is not a vulnerability and is outside that scope. Gold Open Source (free, no login) and Gold Registry (paid, hardened signed images) matter only if your replacement plan includes running your own resolver software: check the version you deploy against known CVEs, and start resolver containers from a patched, signed image rather than whatever tag is newest. We are not claiming Gold has anything specific to this event; both are described in the next section.

FAQ

Is Quad9 shutting down?

No. Quad9 says it will stop serving users in France from 24 November 2026. Its post does not announce changes elsewhere.

I am in Germany, Belgium or Spain. Do I need to do anything?

Not because of this announcement, according to Quad9. Check whether any of your traffic leaves through France: branch offices, cloud regions, VPN or SASE exits, and staff who travel. Also note Quad9's own reference to about 20 pending cases in France and its past case in Germany; build resolver diversity anyway.

Will Quad9 answer with an error, or just stop responding?

Unknown. TorrentFreak reports Quad9 has not decided. Plan for timeouts, which are the slowest failure, and confirm your secondary resolver takes over.

Is 149.112.112.112 a valid backup for 9.9.9.9?

No. It is the same Quad9 service. Use a different operator or your own resolver.

Does this affect DNS over HTTPS and DNS over TLS to dns.quad9.net?

Quad9 talks about withdrawing its services from French users generally and does not exempt any protocol. Treat https://dns.quad9.net/dns-query and tls://dns.quad9.net, and the dns10 and dns11 variants, as affected.

Will a VPN keep Quad9 working from France?

Quad9 itself says users evaded its geographic blocking in Germany with VPNs. We do not recommend relying on that. It would make your production resolution depend on a workaround to a legal measure, and on where a VPN provider exits.

Why did Quad9 not just block the 58 domains?

Quad9 says it will not alter DNS answers in ways users do not expect, cannot reliably identify French users, and will not apply a French ruling worldwide. It also says it cannot afford penalties across about 20 more cases. beIN's position, as reflected in its filings, is that public resolvers should block these domains as French ISPs do.

We used Quad9 for malware blocking. Are we less safe now?

You lose one layer, not all of them. If DNS filtering was a documented control, replace it with an equivalent service or your own resolver with threat intelligence feeds, and update your control records. Endpoint, proxy and email controls are unchanged.

Fix it without waiting for upstream

This event is a configuration change, not a vulnerability, so most of the section below applies to the software you build and ship rather than to resolver settings. It becomes relevant if your plan includes new resolver containers or images, or if the search turns up stale base images you have been meaning to rebuild.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

The CLI demo is a real session fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, and runs install and tests with approval. For the Quad9 exit, you would run the same loop in your infrastructure repository: ask it to find every Quad9 address and hostname, replace the CoreDNS forward block or a netplan nameserver list, and run the dig checks, approving each command. The demo does not show this event.

Click through it at your own pace, or open it full screen.

The desktop app demo is a real session: the CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with an upgrade done and tests passing. Here, you would pick the folder holding your router exports or Ansible roles and ask it to change the DNS servers, reviewing each file edit before it is written.

Click through it at your own pace, or open it full screen.

The mobile demo is a real Android session: you send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. If something you missed starts failing in a French office on the morning of 24 November, that is how an on call engineer could approve a forwarder change from wherever they are.

Click through it at your own pace, or open it full screen.

To try the CLI on your own infrastructure repository, download Safeguard and follow the CLI docs. For finding which products contain a given component during an incident, see SBOM incident response.

Quick check

Sources

• Quad9: Au revoir, France (22 Oct 2026)
• Quad9: Service addresses and features
• Quad9: FAQ
• TorrentFreak: DNS resolver Quad9 will leave France after court orders piracy blocking penalty
• Télé Satellite et Numérique: Piratage, condamné à une astreinte à la demande de beIN Sports, Quad9 quitte la France
• JustGeek: Quad9 quitte la France
• Kulturegeek: Quad9 quitte la France après une décision de justice
• TorrentFreak: OpenDNS suspends service in France due to Canal+ piracy blocking order (2024)
• Wikipedia: Quad9
• Microsoft Learn: Secure DNS Client over HTTPS (DoH) on Windows Server
• systemd: resolved.conf manual
• CoreDNS: forward plugin
• AWS: Managing Route 53 Resolver forwarding rules

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.