DNS Quad9 (9.9.9.9) : fonctionnement, avantages, alternatives

⚡TL;DR

• 📢 Quad9 (9.9.9.9) est un résolveur DNS public axé sécurité et confidentialité, simple à déployer en PME.
• Utilisez 9.9.9.9 pour le service "Secure" (blocage de domaines malveillants + DNSSEC) ; gardez 9.9.9.10 uniquement pour du debug.
• Pour éviter l'espionnage et les redirections DNS, privilégiez un transport chiffré (DoT ou DoH) et vérifiez le protocole réellement utilisé.
• Depuis le 15 décembre 2025, Quad9 ne supporte plus le DoH sur HTTP/1.1 : tout client DoH doit parler HTTP/2 (sinon, basculez vers DoT).

Votre DNS "par défaut" (souvent celui du FAI, ou celui fourni via DHCP sur le réseau) est rarement un choix volontaire. Pourtant, le résolveur DNS voit tous les noms de domaines que vos machines essaient d'atteindre et il peut aussi influencer la sécurité (blocage de domaines malveillants) et la disponibilité (pannes, latence, erreurs).

Quad9 est une alternative populaire quand on veut un DNS public orienté sécurité + vie privée : il peut bloquer des domaines associés à du malware/phishing et annonce une politique de collecte minimale (notamment pas d'enregistrement d'adresses IP côté service DNS). C'est typiquement utile pour des admins sys / DevOps / CTO de PME qui veulent un gain de sécurité "tout de suite", sans déployer un proxy ou un agent sur chaque machine.

On va voir comment Quad9 fonctionne, quelles adresses utiliser (9.9.9.9 / 9.9.9.10 / 9.9.9.11), comment le configurer proprement (routeur, postes, forwarder interne), comment tester ce qui se passe vraiment… et la nouveauté à connaître : la fin du DoH sur HTTP/1.1 depuis le 15 décembre 2025.

Quad9 et 9.9.9.9 en deux minutes

Quad9 est un résolveur DNS récursif public (un service de résolution DNS que vous pouvez utiliser à la place de celui de votre FAI). Il est principalement connu pour :

• Le filtrage de menaces : sur le service "Secure", Quad9 peut refuser la résolution de domaines associés à du malware, du phishing, des botnets, etc.
• La validation DNSSEC (sur les services "Secure") : la résolution échoue si une réponse DNS signée est falsifiée.
• La confidentialité : Quad9 indique ne pas collecter ni enregistrer les adresses IP sur son service de résolution DNS, et limiter sa collecte à des données agrégées.
• Le chiffrement : vous pouvez utiliser Quad9 en DNS classique (Do53) ou en DNS chiffré via DoT (DNS‑over‑TLS) et DoH (DNS‑over‑HTTPS), et aussi via DNSCrypt.

Le point d'entrée le plus connu est 9.9.9.9 (et son "secondaire" IPv4 149.112.112.112) : c'est le service "Secure", généralement le bon choix quand vous ne voulez pas trop réfléchir.

Comment Quad9 résout un nom de domaine ?

Quand un poste tente d'atteindre api.captaindns.com, il ne connaît pas l'IP. Il pose donc une question DNS.

Avec Quad9, le chemin ressemble à ça :

1. Le poste envoie une requête DNS (via l'OS, le routeur, un forwarder…).
2. Quad9 reçoit la requête et regarde d'abord son cache.
3. Si pas en cache, Quad9 effectue la résolution récursive (racine → TLD → serveurs autoritatifs).
4. Sur le service "Secure", Quad9 compare aussi le domaine à des informations de menace :
   • si le domaine est identifié comme malveillant, Quad9 renvoie typiquement un NXDOMAIN (le domaine "n'existe pas" du point de vue du client).
5. Si la résolution implique DNSSEC et que la validation échoue, la réponse peut être un SERVFAIL (échec de validation).

Ce que vous voyez côté client quand ça bloque

C'est un point important en exploitation : un blocage DNS ressemble souvent à "Internet ne marche pas".

• Si Quad9 bloque un domaine malveillant : vous obtenez NXDOMAIN.
• Si le domaine n'existe vraiment pas : vous obtenez aussi NXDOMAIN.
• Si DNSSEC échoue : souvent SERVFAIL.

L'astuce pratique : Quad9 fournit des moyens de différencier "NXDOMAIN parce que bloqué" vs "NXDOMAIN parce que réellement inexistant" (on y revient dans la section tests).

Avantages et limites de Quad9

Ce que Quad9 apporte immédiatement

• Réduction du risque "au clic" : une partie des domaines malveillants ne résolvent plus.
• Moins de fuites DNS si vous activez DoT/DoH : un Wi‑Fi public voit beaucoup moins facilement ce que vous résolvez.
• DNSSEC déjà validé sur les services Secure : moins de risque d'empoisonnement ou de réponses falsifiées sur des zones signées.
• Déploiement léger : un changement de DNS au routeur ou un forwarder local suffit souvent.

Ce que Quad9 ne remplace pas

• Un proxy web ou un produit SASE : Quad9 agit au niveau DNS, pas au niveau URL, HTTP, ou inspection TLS.
• Un adblocker : Quad9 est orienté "menaces", pas "publicités/trackers" (même si certains domaines peuvent se recouper).
• Une politique par utilisateur/poste : vous n'avez pas, nativement, des profils "Marketing vs Dev vs Invités" comme dans des solutions DNS managées plus "entreprise".

Le bon cadrage : Quad9 est une couche de base (souvent très rentable), pas un bouclier unique.

Les services Quad9 à connaître

Quad9 ne fournit pas "un seul DNS", mais plusieurs variantes. En pratique, vous allez surtout croiser ces trois-là :

Service	À utiliser quand	Filtrage menaces	DNSSEC	ECS	Adresses IPv4
9.9.9.9 "Secure"	Cas général, PME, postes, Wi‑Fi invités	✅	✅	❌	9.9.9.9, 149.112.112.112
9.9.9.10 "No Threat Blocking"	Debug, comparaisons, besoins spécifiques	❌	❌	❌	9.9.9.10, 149.112.112.10
9.9.9.11 "Secure + ECS"	Problèmes de géoloc CDN/perf, cas réseau atypique	✅	✅	✅	9.9.9.11, 149.112.112.11

Les adresses et endpoints utiles

Service Secure (recommandé) :

IPv4 : 9.9.9.9, 149.112.112.112
IPv6 : 2620:fe::fe, 2620:fe::9
DoT  : dns.quad9.net (port 853)
DoH  : https://dns.quad9.net/dns-query

Service No Threat Blocking :

IPv4 : 9.9.9.10, 149.112.112.10
IPv6 : 2620:fe::10, 2620:fe::fe:10
DoT  : dns10.quad9.net (port 853)
DoH  : https://dns10.quad9.net/dns-query

Service Secure + ECS :

IPv4 : 9.9.9.11, 149.112.112.11
IPv6 : 2620:fe::11, 2620:fe::fe:11
DoT  : dns11.quad9.net (port 853)
DoH  : https://dns11.quad9.net/dns-query

Faut-il activer ECS

ECS (EDNS Client Subnet) transmet une information partielle de localisation (une portion du préfixe IP) vers des serveurs autoritatifs/CDN. Résultat : vous pouvez obtenir un "meilleur" POP CDN (latence moindre) dans certains réseaux où l'anycast vous envoie vers un site Quad9 qui n'est pas idéal pour votre géographie réelle.

Le compromis :

• ✅ Potentiellement meilleure perf CDN (vidéo, grosses plateformes).
• ❌ Moins de confidentialité, car une partie de votre préfixe sert à la géolocalisation.

En pratique : commencez par 9.9.9.9, ne basculez vers 9.9.9.11 que si vous observez un vrai problème (latence anormale vers un service, mauvaise géoloc, etc.).

Do53, DoT, DoH et DNSCrypt

On confond souvent "changer de DNS" et "chiffrer son DNS". Ce n'est pas pareil.

Do53

Do53 est le DNS "classique" : UDP/53 (et parfois TCP/53). Facile, universel, mais :

• visible (sniffable) sur le réseau,
• redirigeable (certains réseaux interceptent le port 53),
• plus simple à manipuler pour un attaquant local (Wi‑Fi public, réseau invité…).

DoT

DoT (DNS‑over‑TLS) chiffre DNS au niveau transport (TCP + TLS, généralement port 853). Avantages :

• souvent disponible au niveau OS (notamment Android via "DNS privé", Linux via systemd‑resolved, etc.),
• plus simple à proxyfier dans un routeur/forwarder,
• pas d'enrobage HTTP : moins de surprises côté clients.

DoH

DoH (DNS‑over‑HTTPS) encapsule DNS dans HTTPS (port 443). C'est pratique dans les environnements où 853 est filtré, mais plus "webby".

Point important pour Quad9 : le support DoH via HTTP/1.1 a été retiré à partir du 15 décembre 2025. Concrètement, un client DoH doit être compatible HTTP/2 (ou supérieur).

DNSCrypt

DNSCrypt est un protocole de chiffrement DNS alternatif, surtout présent dans certains clients/proxys (dnscrypt‑proxy, certaines appliances, etc.). Vous l'utiliserez surtout si vous avez déjà un outillage DNSCrypt ou des contraintes spécifiques.

Performance DNS : comment se faire une idée sans se tromper

"Quel DNS est le plus rapide ?" est une question piégeuse, parce que :

• le cache (local + côté résolveur) fausse les tests,
• la perf dépend de votre réseau, de l'anycast et du peering,
• certaines applis ressentent surtout la latence "première résolution", d'autres profitent du cache.

Une méthode simple et honnête :

1. Testez plusieurs noms (CDN, SaaS, domaines internes).
2. Répétez les tests à différents moments.
3. Comparez Do53 et DoT/DoH si vous envisagez le chiffrement.

Exemple rapide avec dig (à répéter sur plusieurs domaines) :

dig @9.9.9.9 www.captaindns.com A +tries=1 +time=2
dig @149.112.112.112 www.captaindns.com A +tries=1 +time=2

Si vous avez un forwarder local (Unbound/dnsdist), mesurez aussi la latence "vue par vos postes", pas uniquement celle vue par le forwarder.

Configurer Quad9 en pratique

Choisir où configurer

Vous avez 3 niveaux possibles, et ils ne couvrent pas les mêmes besoins :

1. Au niveau routeur/DHCP : simple, couvre "presque tout", mais souvent en Do53 (donc non chiffré).
2. Au niveau poste/OS : bon pour DoT/DoH natifs, utile sur laptops nomades.
3. Via un forwarder local (recommandé en PME si vous voulez du chiffrement partout) : les postes parlent au DNS local, et le DNS local parle en DoT/DoH vers Quad9.

Option 1 : Routeur et DHCP

Objectif : tous les postes utilisent Quad9 sans toucher chaque machine.

• Configurez le DNS primaire/secondaire du LAN sur :
  • 9.9.9.9 et 149.112.112.112
  • (et idéalement les IPv6 correspondantes si votre LAN utilise IPv6)

À garder en tête :

• Un poste peut "tricher" en mettant un DNS statique (ou en activant DoH côté navigateur).
• Sur un réseau "hostile" (hôtel, hotspot), le port 53 peut être intercepté.

Option 2 : Postes et serveurs Linux avec systemd‑resolved

Exemple simple en DoT (à adapter à votre distribution) :

# /etc/systemd/resolved.conf
[Resolve]
DNS=9.9.9.9 149.112.112.112
DNSOverTLS=yes
DNSSEC=no

Appliquez :

sudo systemctl restart systemd-resolved
resolvectl status

⚠️ Évitez d'activer DNSSEC côté forwarder/OS "en plus" si vous utilisez déjà un upstream qui valide DNSSEC : vous risquez une double validation inutile, voire des comportements pénibles selon l'implémentation.

Option 3 : Forcer le chiffrement via un forwarder local

C'est la stratégie la plus robuste en réseau d'entreprise : les postes utilisent votre DNS interne, et votre DNS interne chiffre vers Quad9.

Exemple avec Unbound (simplifié) :

# /etc/unbound/unbound.conf.d/quad9.conf
forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 9.9.9.9@853#dns.quad9.net
  forward-addr: 149.112.112.112@853#dns.quad9.net

Ce pattern donne plusieurs bénéfices :

• chiffrement vers l'extérieur,
• cache local (réponses plus rapides),
• point de contrôle unique (observabilité, dépannage).

Tester que vous utilisez Quad9 et le bon protocole

Test 1 : Confirmer l'usage de Quad9

Quad9 fournit une page de contrôle : on.quad9.net. Si cette page n'indique pas que vous êtes sur Quad9, c'est qu'un autre DNS est utilisé (VPN, DNS imposé, DNS statique, etc.).

Test 2 : Savoir si c'est chiffré : Do53, DoT ou DoH

Quad9 expose un "test TXT" très pratique.

Sous Linux/macOS :

dig +short txt proto.on.quad9.net.

Sous Windows PowerShell :

Resolve-DnsName -Type txt proto.on.quad9.net.

Réponses possibles (exemples) :

• do53-udp / do53-tcp → DNS non chiffré
• dot → DNS‑over‑TLS
• doh → DNS‑over‑HTTPS
• dnscrypt-udp / dnscrypt-tcp → DNSCrypt

Si vous obtenez NXDOMAIN : votre requête n'est pas partie chez Quad9.

Test 3 : Vérifier un blocage Quad9

Quad9 utilise un domaine de test : isitblocked.org.

dig @9.9.9.9 isitblocked.org | grep "status\|AUTHORITY"

• NXDOMAIN + AUTHORITY: 0 → blocage Quad9
• NXDOMAIN + AUTHORITY: 1 → domaine réellement inexistant

Actualités : fin du DoH sur HTTP/1.1 depuis le 15 décembre 2025

⚠️Actualité

À retenir - ⚠️ Quad9 a retiré le support du DNS‑over‑HTTPS via HTTP/1.1 à partir du 15 décembre 2025.

• Si vous utilisez DoH, vérifiez que vos clients parlent HTTP/2 (la plupart des navigateurs modernes le font déjà).
• Les équipements connus pour poser problème : MikroTik RouterOS configuré en DoH (implémentation DoH sans HTTP/2).
• En cas d'incompatibilité, la voie "sans surprise" est de basculer vers DoT (pas de couche HTTP).

Comment auditer rapidement votre parc DoH

1. Inventaire : qui fait du DoH ? (navigateurs, agents endpoint, routeurs, appliances, forwarders).
2. Test HTTP/2 sur l'endpoint DoH Quad9 :

   curl --http2 -I https://dns.quad9.net/dns-query
   

3. Lister les clients "legacy" : typiquement, des équipements réseau qui ont ajouté DoH tôt, mais sans pile HTTP/2.
4. Décider du fallback (documentez-le !) :
   • fallback vers DoT ?
   • fallback vers Do53 (risque : perte de confidentialité + redirections possibles) ?
5. Rendre le test observable : sur vos forwarders, loggez le protocole réellement utilisé et surveillez les taux de NXDOMAIN/SERVFAIL.

Pièges fréquents en production

Mélanger 9.9.9.9 et 9.9.9.10

C'est tentant (se dire "au moins ça résout"), mais vous perdez :

• la couverture sécurité sur une partie des requêtes,
• la capacité à diagnostiquer (un client "tombe" aléatoirement sur l'un ou l'autre).

Choisissez un seul service par environnement, et tenez-vous-y.

Activer DNSSEC partout

Si vous utilisez un upstream qui valide déjà DNSSEC (comme 9.9.9.9), activer DNSSEC dans tous les maillons peut :

• ralentir,
• complexifier les erreurs,
• multiplier les points où "ça casse".

En général : une validation DNSSEC bien faite au bon endroit vaut mieux que deux validations en cascade.

VPN et DNS "imposé"

Beaucoup d'incidents "Quad9 ne marche pas" viennent d'un DNS forcé (souvent dans un tunnel VPN) ou d'une configuration applicative qui contourne le DNS du réseau.

Réflexe : vérifiez le protocole réellement utilisé avec proto.on.quad9.net, et vérifiez l'IP DNS réellement utilisée sur le poste (pas seulement sur le routeur).

Alternatives à Quad9

Quad9 est un très bon choix "par défaut" quand vous voulez sécurité + vie privée avec un service public. Mais selon vos contraintes, vous pouvez préférer :

• Cloudflare (1.1.1.1) : souvent choisi pour la performance et l'écosystème réseau.
• Google Public DNS (8.8.8.8) : ultra répandu, facile à trouver dans les environnements dev/test.
• Cisco Umbrella / OpenDNS : intéressant si vous êtes déjà dans l'écosystème Cisco et que vous voulez des politiques centralisées.
• NextDNS : utile si vous cherchez une approche "policy‑driven" avec profils par appareil.
• AdGuard DNS : orienté blocage pubs/trackers avec des profils pré‑définis.
• Auto‑hébergé : Unbound/Knot Resolver + listes de blocage (souvent couplé à Pi‑hole) si vous voulez garder le contrôle, au prix de plus d'exploitation.

Le bon réflexe : choisissez d'abord votre priorité (sécurité, confidentialité, conformité, contrôle, performance), puis testez.

Plan d'action

1. Choisissez le service Quad9
   • par défaut : 9.9.9.9 ;
   • passez à 9.9.9.11 uniquement si vous avez un vrai souci de perf CDN ;
   • gardez 9.9.9.10 pour des tests, pas pour la prod.
2. Décidez du point d'intégration
   • routeur/DHCP (simple) ;
   • forwarder local (robuste et chiffré) ;
   • poste/OS (nomades).
3. Déployez en pilote
   • une machine, puis un VLAN, puis tout le LAN.
4. Activez le chiffrement si possible
   • DoT en priorité (souvent le plus stable) ;
   • DoH si vous en avez besoin (mais HTTP/2 obligatoire côté Quad9).
5. Validez objectivement
   • dig +short txt proto.on.quad9.net. doit renvoyer dot ou doh si vous visez le chiffrement.
6. Documentez les exceptions
   • VPN, appliances, IoT, réseaux invités, captive portals.
7. Traitez la nouveauté DoH
   • inventaire des clients DoH ;
   • mise à jour/remplacement des clients HTTP/1.1 (ex : MikroTik en DoH) ;
   • fallback explicite vers DoT si vous ne pouvez pas upgrader.
8. Surveillez les signaux
   • pics de NXDOMAIN/SERVFAIL,
   • plaintes applicatives ("ne résout plus"),
   • erreurs TLS/HTTP côté forwarder.
9. Formalisez
   • une page interne "DNS standard" (adresses, protocoles, exceptions),
   • et une check‑list (voir l'export de cet article).

FAQ

Quad9 est-il gratuit et adapté à une PME ?

Oui. Pour une PME, Quad9 est souvent un bon "gain rapide" : vous réduisez l'exposition aux domaines malveillants, et vous améliorez la confidentialité DNS sans déployer d'infrastructure lourde.

Quelle adresse Quad9 dois-je utiliser au quotidien ?

Dans 90% des cas : 9.9.9.9 et 149.112.112.112. Gardez 9.9.9.10 pour des tests ponctuels, et basculez vers 9.9.9.11 seulement si vous avez identifié un problème de routage/perf CDN.

Comment vérifier que je suis bien en DoT ou DoH ?

Faites un test TXT : dig +short txt proto.on.quad9.net. (ou Resolve-DnsName sous Windows). Si la réponse est dot ou doh, c'est chiffré. Si c'est do53-udp, vous êtes en DNS classique.

Pourquoi un domaine bloqué ressemble à une panne DNS ?

Parce que Quad9 renvoie généralement NXDOMAIN quand il bloque. Pour différencier, utilisez le domaine de test isitblocked.org et regardez la valeur AUTHORITY dans la réponse.

Mon routeur supporte DoH mais plus rien ne résout : que faire ?

Depuis le 15 décembre 2025, Quad9 n'accepte plus DoH en HTTP/1.1. Si votre routeur/client DoH ne supporte pas HTTP/2, basculez vers DoT via un poste/forwarder qui le supporte, ou changez de client DoH.

Quad9 enregistre-t-il mon adresse IP ?

Quad9 indique ne pas collecter ni enregistrer les adresses IP sur son service de résolution DNS, et limiter sa collecte à des compteurs techniques agrégés.

Télécharger les tableaux comparatifs

Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser les chiffres.

• Comparatif des résolveurs DNS publics

Glossaire

• Résolveur récursif : serveur DNS qui fait la résolution complète (cache + requêtes vers racine/TLD/autoritatifs) et renvoie la réponse au client.
• Do53 : DNS classique sur le port 53 (UDP/TCP), non chiffré.
• DoT : DNS‑over‑TLS, DNS chiffré au niveau transport (souvent port 853).
• DoH : DNS‑over‑HTTPS, DNS transporté dans HTTPS (port 443). Chez Quad9, HTTP/2 est requis depuis le 15 décembre 2025.
• DNSSEC : mécanisme cryptographique qui permet de valider l'authenticité des réponses DNS des zones signées.
• NXDOMAIN : code DNS indiquant "ce nom de domaine n'existe pas" (utilisé aussi comme technique de blocage).
• SERVFAIL : code DNS indiquant un échec côté résolution (souvent observé lors d'échecs DNSSEC).
• ECS : EDNS Client Subnet, extension qui transmet un indice de localisation (une partie du préfixe IP) aux autoritatifs/CDN.
• Anycast : routage où plusieurs serveurs partagent la même IP et où le réseau vous envoie vers le point "le plus proche" selon le routage.
• Forwarder DNS : serveur DNS local qui relaie les requêtes vers un upstream (Quad9, autre) et peut ajouter cache, logs, politiques.

Sources officielles

• Quad9 - DOH HTTP/1.1 Retirement December 15, 2025