Quad9 quitte la France le 24 novembre : mettez à jour vos configurations DNS dès maintenant

Quad9, le résolveur DNS axé sur la confidentialité, cessera ses opérations pour les utilisateurs en France le mardi 24 novembre 2026. Cette décision fait suite à une ordonnance d'un tribunal français exigeant que le service bloque des domaines spécifiques associés au piratage sportif, une directive que Quad9 refuse d'appliquer. Les administrateurs système et les propriétaires de homelabs en France doivent immédiatement auditer leurs configurations réseau pour remplacer les adresses Quad9 avant que les services ne tombent en panne.

Ce qui s'est passé

Le 21 octobre, un tribunal français a statué en faveur de beIN, un diffuseur sportif qatari, ordonnant à Quad9 de cesser de résoudre les domaines hébergeant des flux piratés pour les utilisateurs français. Plutôt que de se conformer à cette exigence de censure, Quad9 a annoncé son retrait total du marché français. Bien que le tribunal ait réduit l'amende quotidienne à 1 000 €, Quad9 a cité environ 20 procès en cours comme raison principale de son départ, déclarant qu'il ne peut pas survivre à l'accumulation d'amendes potentielles.

Ce retrait affecte un large éventail d'entités, y compris de grandes institutions françaises telles que EDF, SNCF et DINUM. Il impacte également les utilisateurs individuels qui ont récemment migré vers Quad9 après l'annonce de Mullvad selon laquelle il fermerait son service DNS public chiffré le 2 novembre 2026. Les utilisateurs qui ont suivi les conseils de Mullvad pour passer à Quad9 font face à une seconde migration dans les semaines à venir. Quad9 a averti que le blocage géographique basé sur l'IP est inefficace car les utilisateurs peuvent le contourner via des VPN, rendant la conformité juridiquement risquée sans filtrage exhaustif.

Détails clés

• Date limite : Quad9 cesse de servir les utilisateurs français le 24 novembre 2026.
• IP affectées : 9.9.9.9, 149.112.112.112, 2620:fe::fe, 2620:fe::9 et 9.9.9.10 cesseront de fonctionner pour les connexions françaises.
• Contexte juridique : Quad9 fait face à environ 20 procès en cours liés aux ordonnances de blocage de domaines en France.
• Impact Mullvad : Les utilisateurs migrant depuis le DNS Mullvad (fermeture le 2 novembre) vers Quad9 devront migrer à nouveau peu après.
• Alternatives : Cloudflare et DNS4EU restent disponibles mais se conforment aux ordonnances judiciaires françaises ; Unbound auto-hébergé offre une indépendance mais ne propose pas de requêtes upstream chiffrées par défaut.
• Portée de la configuration : Des modifications sont nécessaires dans les routeurs, Pi-hole, Unbound, systemd-resolved, Docker et les paramètres DNS-over-HTTPS des navigateurs.

Contexte

DNS, ou Domain Name System, traduit les noms de domaine lisibles par l'homme en adresses IP. La plupart des utilisateurs dépendent de résolveurs publics comme Quad9, Cloudflare ou Google plutôt que d'exécuter leurs propres résolveurs récursifs. Les résolveurs axés sur la confidentialité comme Quad9 ont gagné en popularité en promettant de ne pas enregistrer les données des utilisateurs et en résistant aux demandes de censure. Cependant, lorsqu'un résolveur opère dans une juridiction, il est soumis aux lois locales. En France, des précédents juridiques récents ont forcé les principaux fournisseurs à bloquer l'accès aux sites accusés d'héberger du contenu piraté.

L'exécution d'un résolveur récursif local, tel qu'Unbound, permet à une organisation d'interroger directement les racines DNS. Cette approche élimine la dépendance envers des tiers qui pourraient être contraints de filtrer les résultats. Toutefois, les requêtes récursives standard ne sont pas chiffrées, ce qui signifie que les fournisseurs d'accès Internet peuvent toujours voir quels domaines sont demandés. Cet arbitrage entre la confidentialité vis-à-vis du résolveur et la visibilité pour le FAI est une considération clé pour les équipes décidant d'une stratégie de remplacement.

Pourquoi cela compte

Pour les équipes gérant des infrastructures auto-hébergées, les dépendances DNS cachées sont une source fréquente de pannes soudaines. Un fichier de configuration écrit il y a des années peut encore pointer vers 9.9.9.9, provoquant l'échec des services internes ou des appels API externes une fois que le résolveur cesse de répondre. Contrairement à un crash de serveur web, les échecs DNS peuvent être subtils, entraînant des délais d'attente lents plutôt que des erreurs immédiates, ce qui complique le diagnostic lors d'un incident.

Cet événement met en lumière le risque de compter sur des points uniques de défaillance pour des composants critiques de l'infrastructure. Même les organisations à but non lucratif ayant une forte position sur la confidentialité sont vulnérables aux pressions juridiques. Les équipes qui supposaient que Quad9 était une couche stable et neutre doivent désormais reconnaître que les facteurs géopolitiques et juridiques peuvent perturber ces services de manière inattendue. Une audit proactif des paramètres DNS est essentielle pour maintenir la continuité opérationnelle.

De plus, le calendrier coïncide avec le retrait de Mullvad de l'espace DNS public, créant un défi de migration composé. Les administrateurs qui ont récemment mis à jour leurs systèmes pour suivre les meilleures pratiques en matière de confidentialité trouvent désormais ces configurations obsolètes. Cela souligne la nécessité de configurations réseau flexibles et facilement ajustables plutôt que de dépendances codées en dur envers des fournisseurs tiers spécifiques.

Ce que vous pouvez faire

• Auditer les configurations : Exécutez des commandes grep dans /etc, les répertoires personnels et les fichiers docker-compose pour trouver les instances de 9.9.9.9, 149.112.112.112 ou quad9.
• Vérifier les résolveurs actifs : Utilisez resolvectl status sous Linux ou vérifiez les paramètres NetworkManager pour identifier les serveurs DNS actuellement actifs.
• Mettre à jour les paramètres du routeur : Connectez-vous à votre passerelle ou à votre appareil OpenWrt et remplacez les IP Quad9 par des alternatives comme Cloudflare (1.1.1.1) ou DNS4EU dans les paramètres WAN ou DHCP.
• Reconfigurer les résolveurs locaux : Si vous utilisez Pi-hole ou Unbound, supprimez les forward-zones pointant vers Quad9 et définissez de nouveaux serveurs upstream ou activez la résolution récursive.
• Mettre à jour le DoH du navigateur : Vérifiez les paramètres Firefox et Chrome pour les modèles DNS-over-HTTPS et remplacez les URL personnalisées Quad9 par des alternatives prises en charge.
• Vérifier les changements : Après la mise à jour, videz les caches DNS et testez la résolution des domaines critiques pour assurer la restauration de la connectivité.