Changer le résolveur DNS d'un serveur avant l'arrêt de Quad9 le 24 novembre : Linux, Docker et Windows Server

Le 24 novembre 2026, le résolveur DNS public Quad9 cesse de servir la France. Tout VPS Linux, serveur dédié ou VPS Windows hébergé en France qui l'interroge encore (9.9.9.9, 149.112.112.112 ou leurs équivalents IPv6) perdra la résolution des noms de domaine : apt et dnf échoueront, les certificats Let's Encrypt ne se renouvelleront plus, les serveurs de jeu ne joindront plus leurs API. Notre actualité sur le départ de Quad9 a posé le contexte. Ce guide est la procédure complète pour changer le résolveur DNS d'un serveur à l'endroit où il est réellement configuré, puis pour prouver, avant la date butoir, que plus rien ne dépend de Quad9.

Il couvre Ubuntu et Debian avec netplan et systemd-resolved, Debian avec ifupdown, Rocky Linux, AlmaLinux et Fedora avec NetworkManager, le résolveur récursif local Unbound, les conteneurs Docker, Pterodactyl Wings, Proxmox VE et nginx, puis Windows Server : client DNS, rôle Serveur DNS et DNS over HTTPS. Sur Windows, la question croise une autre échéance de fin d'année : la fin du support de Windows Server 2016, le 12 janvier 2027.

Ce qui s'arrête le 24 novembre 2026

Quad9, fondation suisse à but non lucratif, a annoncé le 22 octobre 2026 qu'elle retirait ses services de France à compter du mardi 24 novembre 2026. La veille, un tribunal français lui avait donné tort face à beIN, qui exige le blocage de domaines accusés de diffuser illégalement ses retransmissions sportives ; un appel est en cours. Plutôt que de filtrer ces domaines au niveau du résolveur, Quad9 se retire du pays. Source : billet « Au revoir, France » de Quad9, 22 octobre 2026.

Le billet ne détaille pas la méthode technique du retrait et rappelle que Quad9 ne tient aucune base associant ses utilisateurs à un pays. La règle à retenir pour un administrateur : un serveur hébergé dans un datacenter en France doit être traité comme concerné, et les trois services de Quad9 avec lui, pas seulement l'adresse 9.9.9.9.

Une panne de résolveur DNS ne prévient pas. Selon la façon dont le service sera coupé (absence de réponse ou refus), le client peut attendre jusqu'à son délai d'expiration avant de passer au serveur DNS suivant : 5 secondes par tentative avec la configuration par défaut de la glibc. Un serveur qui a un résolveur secondaire d'un autre opérateur continuera de fonctionner, mais ralenti à chaque résolution de nom. Un serveur configuré uniquement avec Quad9 perdra d'un coup tout accès à Internet par nom de domaine.

Résolveur récursif, serveur faisant autorité, stub : le vocabulaire utile

Changer de résolveur DNS est une opération courte, à condition de savoir quelle pièce on remplace. Six notions suffisent :

• Résolveur récursif : le serveur DNS qui reçoit la question « quelle est l'adresse IP de deb.debian.org ? », interroge les serveurs racine, puis ceux du domaine de premier niveau, puis le serveur faisant autorité, met la réponse en cache et la renvoie. Quad9, Cloudflare 1.1.1.1, Google Public DNS et un Unbound installé sur votre machine sont des résolveurs récursifs.
• Serveur faisant autorité : le serveur qui détient la zone DNS d'un nom de domaine (enregistrements A, AAAA, MX, CNAME, SRV). Changer de résolveur ne touche pas à la zone DNS de vos propres domaines : vos enregistrements restent chez votre registrar ou votre hébergeur DNS.
• Résolveur de souche (stub resolver) : la partie du système qui pose les questions. Sous Linux, c'est la glibc qui lit /etc/resolv.conf, ou systemd-resolved qui écoute sur 127.0.0.53 et relaie vers les résolveurs configurés.
• Redirecteur (forwarder) : un serveur DNS qui ne résout pas lui-même et transmet les requêtes à un résolveur amont. Le rôle Serveur DNS de Windows Server, dnsmasq ou Unbound en mode forward-zone fonctionnent ainsi.
• DNS over TLS (DoT) et DNS over HTTPS (DoH) : le chiffrement de la requête DNS entre votre serveur et le résolveur. Le nom TLS (par exemple dns.quad9.net) sert à vérifier le certificat du résolveur.
• TTL et cache DNS : la durée pendant laquelle une réponse reste en cache. Après un changement de résolveur, videz le cache local pour tester la nouvelle configuration et non une réponse mémorisée.

Étape 1 : trouver toutes les occurrences de Quad9 sur le serveur

L'erreur classique consiste à corriger /etc/resolv.conf à la main, à constater que dig répond, puis à voir Quad9 revenir au redémarrage suivant, parce que le fichier était généré par un autre outil. Commencez par identifier qui écrit la configuration DNS du serveur :

ls -l /etc/resolv.conf
cat /etc/resolv.conf
resolvectl status

Si /etc/resolv.conf est un lien vers /run/systemd/resolve/stub-resolv.conf et ne contient que nameserver 127.0.0.53, c'est systemd-resolved qui décide. Lisez alors la sortie de resolvectl status : la section Global affiche les serveurs définis dans resolved.conf (ligne DNS Servers) et la liste de secours (ligne Fallback DNS Servers), chaque section Link affiche les serveurs propres à une interface réseau, venus de netplan, de systemd-networkd ou du DHCP. La ligne Current DNS Server indique le serveur réellement interrogé à cet instant.

Cherchez ensuite les adresses de Quad9 partout où un logiciel a pu les recevoir en dur, y compris dans les fichiers de configuration applicatifs :

sudo grep -rnE '9\.9\.9\.(9|10|11)\b|149\.112\.112\.(112|10|11)\b|2620:fe::|quad9' \
  /etc /opt /srv /root /home 2>/dev/null

Les emplacements qui reviennent le plus souvent, et où corriger :

Deux cas ne laissent aucune trace dans /etc. Si Quad9 apparaît dans une section Link de resolvectl status mais dans aucun fichier, l'adresse est distribuée par le DHCP : il faudra demander au système d'ignorer les serveurs DNS reçus par DHCP. Si Quad9 n'apparaît que dans Fallback DNS Servers, c'est la liste de secours compilée dans systemd-resolved : la valeur par défaut du projet systemd contient Cloudflare, Google et Quad9. Debian et Ubuntu compilent systemd avec une liste de secours vide, d'autres distributions gardent celle du projet. Elle ne sert que si aucun autre serveur DNS n'est connu, mais autant la fixer explicitement à l'étape 3a.

Si vous découvrez un problème de résolution plus large en chemin, notre guide pour diagnostiquer une résolution DNS défaillante sous Linux détaille l'usage de getent, dig et resolvectl.

Étape 2 : choisir le résolveur DNS de remplacement

Pour un serveur, les critères ne sont pas ceux d'un poste de travail : disponibilité, latence depuis le datacenter, validation DNSSEC et, surtout, deux opérateurs indépendants en DNS primaire et DNS secondaire, pour que la panne de l'un ne coupe pas le serveur. Les options courantes, avec leurs adresses publiées :

DNS4EU est un résolveur public européen opéré par la société tchèque Whalebone, sur une infrastructure située dans l'Union européenne. Son site précise que les blocages de domaines ordonnés par un tribunal s'appliquent à toutes ses variantes. Pour un serveur, ces blocages visent des domaines précis désignés par la justice, pas les dépôts de paquets, Steam, Let's Encrypt ou les API dont dépendent vos services.

Notre recommandation pour un serveur hébergé en France :

• Autonomie maximale : un résolveur récursif Unbound sur le serveur (section dédiée plus bas). Il interroge directement les serveurs racine et ne dépend d'aucun résolveur public.
• Simplicité : deux opérateurs différents, par exemple Cloudflare en primaire et DNS4EU Unfiltered en secondaire. Ne mettez jamais deux adresses d'un même opérateur pour seule redondance : c'est précisément la situation des serveurs configurés en 9.9.9.9 et 149.112.112.112.
• Remplacer le filtrage de Quad9 : si vous utilisiez Quad9 pour son blocage des domaines malveillants, les équivalents sont 1.1.1.2 et 1.0.0.2 chez Cloudflare ou la variante Protective de DNS4EU. Ne mélangez pas un résolveur filtrant et un résolveur non filtrant : selon le serveur interrogé, un même domaine serait tantôt bloqué, tantôt résolu.

Les exemples de ce guide utilisent Cloudflare et DNS4EU Unfiltered. Remplacez-les par votre choix.

Étape 3a : Ubuntu et Debian avec netplan et systemd-resolved

Sur Ubuntu Server, et sur toute Debian dont le réseau est géré par netplan, la configuration réseau vit dans /etc/netplan/ et systemd-resolved sert de résolveur de souche. Sauvegardez d'abord le fichier hors du dossier netplan (une copie en .yaml laissée dans /etc/netplan/ serait lue elle aussi) :

ls /etc/netplan/
sudo cp /etc/netplan/50-cloud-init.yaml /root/50-cloud-init.yaml.bak

Dans le bloc de l'interface, remplacez ou ajoutez la clé nameservers. Si l'interface est en DHCP, ajoutez aussi dhcp4-overrides : la documentation de netplan indique que, par défaut, les serveurs DNS reçus par DHCP sont utilisés et passent avant ceux configurés en statique (cette option agit avec le moteur systemd-networkd, celui d'Ubuntu Server). Exemple avec une interface eth0 en DHCP :

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      dhcp4-overrides:
        use-dns: false
      nameservers:
        addresses:
          - 1.1.1.1
          - 86.54.11.100
          - 2606:4700:4700::1111
          - 2a13:1001::86:54:11:100

Pour une interface configurée en adresse IP statique, ne gardez que le bloc nameservers sous les clés addresses et routes existantes. Appliquez ensuite avec netplan try plutôt qu'avec netplan apply : la commande applique la configuration et revient automatiquement en arrière au bout de 120 secondes si vous ne confirmez pas, ce qui évite de perdre la session SSH sur une faute de frappe.

sudo netplan try
resolvectl status

Si l'en-tête du fichier indique qu'il est généré par cloud-init, une modification directe risque de ne pas survivre. La documentation de cloud-init prévoit de désactiver sa gestion du réseau par un fichier placé dans /etc/cloud/cloud.cfg.d/ :

echo 'network: {config: disabled}' | sudo tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

Fixez ensuite la configuration globale de systemd-resolved dans un fichier de surcharge, plutôt que dans /etc/systemd/resolved.conf que le paquet peut mettre à jour :

sudo mkdir -p /etc/systemd/resolved.conf.d
sudo tee /etc/systemd/resolved.conf.d/10-sans-quad9.conf <<'EOF'
[Resolve]
DNS=1.1.1.1#one.one.one.one 86.54.11.100#unfiltered.joindns4.eu
FallbackDNS=8.8.8.8#dns.google 2001:4860:4860::8888#dns.google
EOF
sudo systemctl restart systemd-resolved
resolvectl flush-caches
resolvectl status

Un point que beaucoup d'administrateurs découvrent trop tard : d'après la page de manuel de resolved.conf, les serveurs globaux de la ligne DNS= sont interrogés en parallèle des serveurs propres à chaque interface. Ajouter Cloudflare en global ne retire donc pas Quad9 s'il reste configuré sur l'interface : corrigez netplan d'abord, la surcharge globale ensuite. La ligne FallbackDNS= remplace la liste de secours compilée, qui peut contenir Quad9 selon la distribution.

Pour chiffrer les requêtes, ajoutez DNSOverTLS=yes dans la section [Resolve]. Le suffixe #one.one.one.one de chaque adresse est le nom TLS que systemd-resolved vérifie sur le certificat du résolveur. Le DNS over TLS passe par le port TCP 853 : si votre pare-feu filtre le trafic sortant, autorisez-le, comme le port 53 en UDP et TCP pour le DNS classique. Notre guide sur l'ouverture des ports avec UFW rappelle la syntaxe des règles.

Étape 3b : Debian avec ifupdown ou un resolv.conf statique

Sur une Debian installée sans systemd-resolved, /etc/resolv.conf est un fichier ordinaire. Si aucun outil ne le régénère, éditez-le directement. La glibc lit au plus trois lignes nameserver, dans l'ordre :

nameserver 1.1.1.1
nameserver 86.54.11.100
options timeout:2 attempts:2

L'option timeout:2 ramène à 2 secondes l'attente avant de passer au serveur DNS suivant, au lieu de 5 par défaut. Vérifiez ensuite qu'aucun outil ne réécrira le fichier :

• Paquet resolvconf installé (dpkg -l resolvconf) : le fichier est généré à partir des lignes dns-nameservers de /etc/network/interfaces et des fichiers /etc/resolvconf/resolv.conf.d/head, base et tail. Corrigez la ligne dans le bloc de l'interface :

  iface eth0 inet static
      address 203.0.113.10/24
      gateway 203.0.113.1
      dns-nameservers 1.1.1.1 86.54.11.100

  La nouvelle valeur est prise en compte quand l'interface est relancée. Ne faites pas ifdown en SSH : passez par la console VNC de l'espace client, ou redémarrez le serveur à un moment calme.
• Interface en DHCP avec dhclient : le client DHCP réécrit /etc/resolv.conf à chaque renouvellement de bail. Imposez vos résolveurs dans /etc/dhcp/dhclient.conf avec la ligne supersede domain-name-servers 1.1.1.1, 86.54.11.100;.

Si vous prévoyez de toute façon une montée de version, notre guide pour migrer un VPS de Debian 12 vers Debian 13 rappelle les vérifications réseau à faire après la mise à niveau : c'est le bon moment pour contrôler le résolveur.

Étape 3c : Rocky Linux, AlmaLinux et Fedora avec NetworkManager

Sur les distributions de la famille Red Hat, NetworkManager gère les connexions et écrit /etc/resolv.conf. Modifier ce fichier à la main ne sert à rien : il sera régénéré. Passez par nmcli, en remplaçant eth0 par le nom de la connexion affiché par la première commande :

nmcli -g NAME,DEVICE connection show --active
sudo nmcli connection modify "eth0" ipv4.dns "1.1.1.1 86.54.11.100" ipv4.ignore-auto-dns yes
sudo nmcli connection modify "eth0" ipv6.dns "2606:4700:4700::1111 2a13:1001::86:54:11:100" ipv6.ignore-auto-dns yes
sudo nmcli connection up "eth0"
cat /etc/resolv.conf

La propriété ignore-auto-dns fait ignorer les serveurs DNS et les domaines de recherche reçus automatiquement (DHCP, annonces IPv6) : seuls ceux que vous avez saisis restent. C'est l'équivalent de use-dns: false chez netplan. La réactivation de la connexion peut couper brièvement le réseau : gardez la console VNC ouverte si le serveur est distant.

Option autonome : un résolveur récursif Unbound sur le serveur

Unbound, développé par NLnet Labs, est un résolveur DNS récursif léger qui valide DNSSEC. Installé sur le serveur, il supprime toute dépendance à un résolveur public : c'est la réponse la plus durable à un événement comme le départ de Quad9. Sur Debian et Ubuntu :

sudo apt install -y unbound
sudo systemctl enable --now unbound
dig @127.0.0.1 deb.debian.org +short
dig @127.0.0.1 debian.org +dnssec | grep flags

Le paquet Debian charge tous les fichiers de /etc/unbound/unbound.conf.d/, dont root-auto-trust-anchor-file.conf, qui active la validation DNSSEC avec une ancre de confiance de la racine tenue à jour automatiquement. La présence du drapeau ad dans la ligne flags de la seconde commande confirme qu'une réponse a été validée. Sans directive interface, Unbound n'écoute que sur localhost et refuse les requêtes venues d'ailleurs que de 127.0.0.0/8 : il ne devient pas un résolveur ouvert sur Internet, ce qui doit rester le cas. N'ouvrez jamais le port 53 sur l'adresse IP publique du serveur.

Pointez ensuite le système vers 127.0.0.1 à l'endroit identifié à l'étape 1 : bloc nameservers de netplan, ligne DNS= de systemd-resolved, ligne nameserver de /etc/resolv.conf ou propriété ipv4.dns de NetworkManager. Il n'y a pas de conflit de port avec systemd-resolved, qui écoute sur 127.0.0.53. Unbound doit pouvoir joindre les serveurs racine et les serveurs faisant autorité en UDP et TCP sur le port 53 en sortie.

Si vous préférez déléguer la récursion à des résolveurs publics tout en chiffrant le trajet, Unbound peut servir de redirecteur DNS over TLS. Créez /etc/unbound/unbound.conf.d/forward-tls.conf :

server:
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#one.one.one.one
    forward-addr: 86.54.11.100@853#unfiltered.joindns4.eu

Validez avec sudo unbound-checkconf, puis sudo systemctl restart unbound. Vous gardez le cache local d'Unbound, qui accélère les résolutions répétées, et le chiffrement jusqu'au résolveur amont.

Docker, Pterodactyl Wings, Proxmox VE et nginx : les résolveurs codés en dur

Corriger le système ne suffit pas toujours : plusieurs logiciels serveur portent leur propre liste de résolveurs DNS.

Docker et Docker Compose

D'après la documentation de Docker, un conteneur hérite par défaut de la configuration DNS de l'hôte : il reçoit une copie de /etc/resolv.conf sur le réseau bridge par défaut, et passe par le serveur DNS embarqué de Docker (127.0.0.11), qui relaie vers les résolveurs de l'hôte, sur les réseaux personnalisés. Si l'étape 1 a trouvé Quad9 dans /etc/docker/daemon.json, remplacez la clé dns :

{
  "dns": ["1.1.1.1", "86.54.11.100"]
}

Le redémarrage du démon (sudo systemctl restart docker) arrête les conteneurs en cours, sauf si l'option live-restore est active : faites-le pendant une fenêtre de maintenance. Dans un fichier Compose, la clé dns se place au niveau du service :

services:
  app:
    image: mon-image
    dns:
      - 1.1.1.1
      - 86.54.11.100

Recréez ensuite les conteneurs avec docker compose up -d --force-recreate et testez depuis l'intérieur d'un conteneur : docker run --rm alpine nslookup deb.debian.org. Pour la structure d'un fichier Compose, voir notre guide Docker Compose sur un VPS Linux.

Pterodactyl Wings

Wings, le démon de Pterodactyl qui fait tourner les serveurs de jeu dans des conteneurs, impose sa propre liste de résolveurs à chaque serveur. Elle se trouve dans /etc/pterodactyl/config.yml, sous docker.network.dns. La valeur par défaut du code de Wings est 1.1.1.1 et 1.0.0.1 : vous n'êtes concerné que si quelqu'un l'a remplacée par Quad9.

docker:
  network:
    dns:
      - 1.1.1.1
      - 86.54.11.100

Redémarrez Wings (sudo systemctl restart wings), puis redémarrez chaque serveur de jeu depuis le panel. Un serveur FiveM, Minecraft ou Rust sans résolution DNS perd l'authentification Steam, le téléchargement des ressources et les appels aux API externes.

Proxmox VE et conteneurs LXC

Sur un hôte Proxmox VE, le résolveur se règle dans l'interface web (nœud, puis Système, puis DNS), qui écrit /etc/resolv.conf. Les conteneurs LXC ont leur propre option : d'après la documentation de pct, un conteneur créé sans nameserver ni searchdomain reprend les réglages de l'hôte. Vérifiez chaque conteneur et corrigez ceux qui citent Quad9 :

pct config 101 | grep -E 'nameserver|searchdomain'
pct set 101 --nameserver "1.1.1.1 86.54.11.100"

Les machines virtuelles, elles, se corrigent de l'intérieur, avec la méthode de leur système d'exploitation. Notre guide pour sécuriser et mettre à jour Proxmox VE complète cette vérification.

nginx

La directive resolver de nginx désigne les serveurs DNS utilisés pour résoudre les noms des serveurs amont, par exemple un proxy_pass construit avec une variable. Elle ne lit pas /etc/resolv.conf : une ligne resolver 9.9.9.9; continuera d'interroger Quad9 quel que soit le réglage du système.

resolver 1.1.1.1 86.54.11.100 valid=300s;

Contrôlez puis rechargez : sudo nginx -t && sudo systemctl reload nginx. Si votre reverse proxy nginx pointe vers Unbound, écrivez resolver 127.0.0.1;.

VPS Windows : client DNS, rôle Serveur DNS et DNS over HTTPS

Le client DNS de Windows Server

Sur un VPS Windows, listez les serveurs DNS de chaque carte réseau, puis remplacez-les sur l'interface concernée, repérée par son index. Le paramètre -Validate vérifie que les adresses répondent avant de les enregistrer :

Get-DnsClientServerAddress
Set-DnsClientServerAddress -InterfaceIndex 12 -ServerAddresses ("1.1.1.1","86.54.11.100") -Validate
Clear-DnsClientCache
Resolve-DnsName deb.debian.org

D'après la documentation Microsoft, les adresses définies par Set-DnsClientServerAddress remplacent celles distribuées par DHCP sur l'interface. La commande existe dans les mêmes termes de Windows Server 2016 à Windows Server 2025.

Le rôle Serveur DNS et les redirecteurs

Un contrôleur de domaine Active Directory ou un serveur Windows avec le rôle DNS transmet souvent les requêtes externes à des redirecteurs. Si Quad9 en fait partie, remplacez la liste :

Get-DnsServerForwarder
Set-DnsServerForwarder -IPAddress "1.1.1.1","86.54.11.100" -PassThru

Set-DnsServerForwarder écrase la liste existante. Par défaut, le serveur DNS attend 5 secondes la réponse d'un redirecteur avant de passer au suivant, puis tente une récursion classique quand tous ont échoué, sauf si cette récursion a été désactivée (paramètre -UseRootHint). Un contrôleur de domaine resté sur Quad9 risque donc de résoudre avec plusieurs secondes de retard chaque nom absent de son cache, ou de ne plus résoudre du tout.

DNS over HTTPS : à partir de Windows Server 2022 seulement

Le client DNS sait chiffrer ses requêtes en DNS over HTTPS (DoH) à partir de Windows Server 2022. Le chiffrement n'est proposé que si le serveur DNS figure dans la liste des serveurs DoH connus, que Get-DnsClientDohServerAddress affiche. La liste livrée par Microsoft contient Cloudflare, Google et Quad9. Pour DNS4EU, ajoutez l'entrée vous-même :

Get-DnsClientDohServerAddress
Add-DnsClientDohServerAddress -ServerAddress '86.54.11.100' -DohTemplate 'https://unfiltered.joindns4.eu/dns-query' -AllowFallbackToUdp $False -AutoUpgrade $True

Microsoft déconseille d'imposer DoH (mode Require DoH) sur une machine membre d'un domaine : le service Serveur DNS de Windows ne répond pas en DoH, et Active Directory dépend entièrement du DNS.

Encore sous Windows Server 2016 : changer le DNS maintenant, migrer avant le 12 janvier 2027

Windows Server 2016 ne dispose pas du client DoH : sur ce système, le changement de résolveur se limite aux commandes en clair ci-dessus, qui fonctionnent. Il faut les appliquer avant le 24 novembre, sans attendre la migration. Mais l'échéance suivante est proche : d'après la page de cycle de vie de Microsoft, le support étendu de Windows Server 2016 prend fin le 12 janvier 2027 (le 13 janvier à 6 h 59, heure du Pacifique). Après cette date, plus aucun correctif de sécurité gratuit n'est publié.

Les deux chantiers se préparent ensemble. L'inventaire de la migration (rôles installés, services, applications) est l'occasion de relever chaque endroit où un résolveur est codé en dur : redirecteurs du rôle DNS, configuration de la carte réseau, fichiers des serveurs de jeu ou des applications. En cas de réinstallation propre sous Windows Server 2022 ou 2025, notez les résolveurs choisis dans votre procédure pour ne pas réintroduire Quad9 depuis une ancienne documentation interne. Notre actualité sur la fin du support de Windows Server 2016 détaille les options (mise à niveau sur place ou réinstallation, mises à jour de sécurité étendues payantes), et le guide pour sécuriser un VPS Windows Server les réglages à refaire après la migration.

Étape 4 : simuler la coupure de Quad9 avant le 24 novembre

Le seul test qui prouve que plus rien ne dépend de Quad9 consiste à le rendre injoignable avant la date. Sous Linux, une route blackhole temporaire fait disparaître les adresses de Quad9 du point de vue du serveur. Ces routes ne survivent pas à un redémarrage :

for ip in 9.9.9.9 9.9.9.10 9.9.9.11 149.112.112.112 149.112.112.10 149.112.112.11; do
  sudo ip route add blackhole "$ip"/32
done
sudo ip -6 route add blackhole 2620:fe::/48

Le bloc 2620:fe::/48 contient toutes les adresses IPv6 de Quad9 listées plus haut. Lancez ensuite les vérifications qui comptent pour vos services :

resolvectl flush-caches 2>/dev/null
getent hosts deb.debian.org
sudo apt update            # ou : sudo dnf makecache
curl -sI https://acme-v02.api.letsencrypt.org/directory | head -n 1
docker run --rm alpine nslookup deb.debian.org
journalctl -u systemd-resolved --since "10 min ago"

Chaque commande doit répondre sans délai anormal. Un apt update qui met plusieurs secondes à démarrer trahit un résolveur Quad9 resté en premier dans une liste. Retirez ensuite les routes de test :

for ip in 9.9.9.9 9.9.9.10 9.9.9.11 149.112.112.112 149.112.112.10 149.112.112.11; do
  sudo ip route del blackhole "$ip"/32
done
sudo ip -6 route del blackhole 2620:fe::/48

Sous Windows Server, le même test passe par une règle de pare-feu sortante temporaire :

New-NetFirewallRule -DisplayName "Test sans Quad9" -Direction Outbound -Action Block -RemoteAddress 9.9.9.9,149.112.112.112,9.9.9.10,149.112.112.10,9.9.9.11,149.112.112.11
Clear-DnsClientCache
Resolve-DnsName deb.debian.org
Remove-NetFirewallRule -DisplayName "Test sans Quad9"

Checklist avant le 24 novembre

1. Repérer qui gère le DNS du serveur : ls -l /etc/resolv.conf et resolvectl status sous Linux, Get-DnsClientServerAddress sous Windows.
2. Chercher toutes les adresses de Quad9 (les trois services, IPv4 et IPv6) dans /etc, /opt, /srv et les dossiers des applications.
3. Choisir deux résolveurs d'opérateurs différents, ou installer Unbound en résolveur local.
4. Corriger à la source : netplan avec use-dns: false si DHCP, NetworkManager avec ignore-auto-dns, resolv.conf ou dns-nameservers sous Debian.
5. Fixer DNS= et FallbackDNS= dans une surcharge de systemd-resolved.
6. Corriger les listes codées en dur : Docker, Compose, Wings, conteneurs LXC de Proxmox VE, directive resolver de nginx, redirecteurs du rôle DNS Windows.
7. Simuler la coupure avec les routes blackhole ou la règle de pare-feu, tester apt, les certificats, les conteneurs et les serveurs de jeu, puis retirer le test.
8. Sous Windows Server 2016, planifier la migration avant le 12 janvier 2027.