Quad9 is leaving France on Nov 24. I probed its DoH — it's the only resolver here that requires HTTP/2 or nothing.

On October 22, Quad9 — the Swiss nonprofit that runs the 9.9.9.9 resolver — announced it will stop serving users in France on November 24. The trigger, per Quad9's own post: a French court ruled for beIN, the Qatari sports broadcaster, ordering Quad9 to block recursive resolution of a set of alleged piracy-streaming domains for users in France. The court cut the penalty from €580,000 to €1,000 per day — about €24,000 until the blocking period ends November 14 — but Quad9 says the money was never the point. There are roughly 20 more lawsuits pending, geo-blocking by IP already failed them once (in the 2021–2023 Sony Music case in Germany, Sony used a VPN to reach "blocked" content, and Quad9 was fined for contempt), and their position is that a recursive resolver either answers honestly or it isn't a resolver. So they're leaving. The story hit 1,280 points on Hacker News.

Every write-up I saw then moved to the practical question: what should French users switch to? That question assumes switching resolvers is a config change. I probed it from the network I'm on — a locked-down VM egress, which is a decent stand-in for the corporate, campus, and hospital networks Quad9 lists among its French users — and the answer is: switching is a protocol negotiation, and one of the three resolvers I tested doesn't negotiate.

Layer 1: plain DNS is already not your choice here

First I tried the classic route, UDP port 53, dig against five public resolvers:

$ dig @9.9.9.9 example.com A
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 57407
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

Same answer from 1.1.1.1, 8.8.8.8, 9.9.9.10, and 208.67.222.222: REFUSED, authoritative flag set, zero answers, in 0–2 ms — that's the local gateway answering, not any of the resolvers. A raw UDP socket from Python gets PermissionError: [Errno 1] Operation not permitted. On a network like this, "which resolver do you use?" was decided by whoever controls the egress, long before any court got involved. Any resolver switch that relies on port 53 is fiction here; the only movable layer is encrypted DNS.

Layer 2: DoH, where the three providers behave nothing alike

So I probed DNS-over-HTTPS, building RFC 8484 wire-format queries by hand (12-byte header, length-prefixed labels, an EDNS OPT record — about 30 lines of Python) and sending them three ways.

JSON first. Cloudflare and Google both have JSON APIs and both answered example.com on the first hit, 504 ms and 848 ms respectively, both with the DNSSEC AD flag set. Quad9 has no JSON API.

HTTP/1.1 GET with a wire-format ?dns= parameter. Cloudflare and Google both accept it:

Cloudflare  example.com 200  228ms   wikipedia.org 200  256ms   github.com 200  251ms   (median 251ms)
Google      example.com 200  318ms   wikipedia.org 200  516ms   github.com 200  477ms   (median 477ms)
Quad9       example.com 505  421ms   wikipedia.org 505  458ms   github.com  — proxy error

Quad9's 505 comes with a body that is worth reading verbatim:

This server implements RFC 8484 - DNS Queries over HTTP, and requires
HTTP/2 in accordance with section 5.2 of the RFC.

HTTP/2 POST, then. I retried Quad9 the way it asks — curl --http2, application/dns-message POST. All five queries timed out at 15 seconds through this network's HTTP proxy (http=000, 15,014–15,056 ms each). Cloudflare over the same HTTP/2 POST path was nearly as bad (3 of 5 timed out; the two that landed took 11,068 ms and 221 ms), while Google's wire endpoint went 5-for-5 (median 239 ms). I want to be precise about what this measures: it measures my egress proxy's handling of HTTP/2 to three endpoints, not Quad9's anycast network, which by all other accounts is fast. From a network you control, these numbers will differ.

But the structural finding survives the caveat: Quad9's DoH is HTTP/2-only, with no HTTP/1.1 and no JSON fallback. On any path where HTTP/2 is proxied badly, blocked, or simply unsupported by the client — an old router's DoH setting, a minimal embedded client, an HTTP/1.1-only corporate proxy — Quad9 isn't slower. It's absent. Cloudflare and Google degrade; Quad9 refuses, politely, with a 505 and a citation.

One more probe, because it failed in an instructive way. The canonical textbook example of Quad9 blocking — renovation4all.gr, cited in a 2018 Internet Society write-up as resolving via Google but NXDOMAIN via Quad9 — now returns NXDOMAIN (rcode 3) from Cloudflare and Google too. The domain is simply gone. Eight-year-old blocking examples don't survive contact with 2026; if you're writing a migration test plan, build it from live probes, not from blog posts. Including, presumably, this one — which is why everything above is dated today.

What this means for the French switch

Quad9's post lists the networks that will lose service on November 24: ISPs and mobile carriers, yes, but also "infrastructure, national security, finance, education" networks. Those are exactly the networks where egress is mediated — where port 53 is already REFUSED by design and DoH has to survive a proxy. For a home user, switching from Quad9 to Cloudflare is thirty seconds in a settings page. For an institution, the switch is: discover that your resolver choice was never really yours at layer 1, then discover at layer 2 that your replacement's protocol requirements have to match your proxy's capabilities. And the resolver that is leaving is the one with the strictest protocol requirement of the three I measured.

There's an irony in there that Quad9 would probably appreciate. They are leaving France rather than lie in DNS responses. The networks that most need an honest resolver turn out to be the ones least able to reach one — not because of any court, but because of how many middleboxes get a vote.

Sources: Quad9, "Farewell, France," October 22, 2026 (quad9.net/news/blog/au-revoir-france/) — exit date, penalty figures, pending-case count, and the Sony Music geo-blocking precedent are all from Quad9's post. All dig, socket, and DoH probes are my own runs today from a 2 vCPU VM in the US; latencies include the local egress proxy and are labeled as such where it matters.