DNS Cloudflare (1.1.1.1) : confidentialité, DoH/DoT, déploiement

Par CaptainDNS
Publié le 23 décembre 2025

#DNS
#Cloudflare
#1.1.1.1
#Résolveur DNS
#Confidentialité
#DoH
#DoT
#Sécurité

Illustration : 1.1.1.1 (Cloudflare), résolveur DNS public avec options DoH/DoT/ODoH et focus confidentialité

TL;DR

📢 1.1.1.1 est le DNS public de Cloudflare : simple à déployer, et intéressant si vous voulez un DNS "propre" côté confidentialité.
Retenez les 3 variantes utiles : 1.1.1.1 (sans filtrage), 1.1.1.2 (bloque malware), 1.1.1.3 (bloque malware + contenus adultes).
Pour éviter l'écoute et l'interception sur le dernier kilomètre, privilégiez un transport chiffré (DoT/DoH) ou, si votre outillage le supporte, ODoH.
Le point admin : prévoyez une stratégie de secours (second résolveur ou cache local), un incident Cloudflare en 2025 a déjà montré qu'un DNS public peut ne plus répondre.

Votre DNS "par défaut" (souvent celui du FAI via DHCP) est rarement un choix volontaire. Pourtant, le résolveur DNS voit tous les domaines que vos machines tentent de joindre et peut impacter performance, confidentialité, sécurité et disponibilité.

Dans la suite de notre série sur les résolveurs publics, on se concentre sur Cloudflare 1.1.1.1 : ce que c'est, ce que ça promet (et ce que ça ne peut pas promettre), comment l'activer en clair ou en chiffré, comment le tester, et comment l'intégrer proprement en PME.

Public visé : pour le réseau domestique, mais aussi entreprise pour les administrateurs système, les DevOps ou encore CTO de PME qui veulent une configuration pragmatique, auditable et réversible.

1.1.1.1 : de quoi parle-t-on exactement ?

1.1.1.1 est une adresse IP qui pointe vers un résolveur DNS récursif public opéré par Cloudflare. En pratique, configurer vos machines (ou votre routeur) sur 1.1.1.1 signifie :

vos postes envoient leurs requêtes DNS à Cloudflare (au lieu du DNS du FAI),
Cloudflare répond depuis son cache si possible,
sinon Cloudflare résout récursivement (racine → TLD → serveurs autoritatifs) puis renvoie la réponse.

Cloudflare propose aussi des variantes "prêtes à l'emploi" :

1.1.1.1 / 1.0.0.1 : résolveur sans filtrage (réponses DNS "brutes").
1.1.1.2 / 1.0.0.2 : blocage malware (Cloudflare "Families").
1.1.1.3 / 1.0.0.3 : blocage malware + contenus adultes (Cloudflare "Families").

Flux de résolution DNS avec 1.1.1.1 : Do53 vs DoT/DoH

Les adresses et endpoints Cloudflare à connaître (mémo)

Vous allez souvent devoir répondre à ces deux questions :

Quelles IP mettre en primaire/secondaire (IPv4/IPv6) ?
Quel endpoint utiliser si je veux chiffrer (DoH/DoT) ?

Table de référence (à copier-coller dans vos procédures) :

Service	Usage	IPv4	IPv6	DoH (HTTPS)	DoT (TLS)
1.1.1.1 (sans filtrage)	Cas général sans filtrage	`1.1.1.1`, `1.0.0.1`	`2606:4700:4700::1111`, `2606:4700:4700::1001`	`https://cloudflare-dns.com/dns-query`	`one.one.one.one`
Families (malware)	Réduire le risque "au clic"	`1.1.1.2`, `1.0.0.2`	`2606:4700:4700::1112`, `2606:4700:4700::1002`	`https://security.cloudflare-dns.com/dns-query`	`security.cloudflare-dns.com`
Families (adult+malware)	Réseau "famille", invités, lieux publics	`1.1.1.3`, `1.0.0.3`	`2606:4700:4700::1113`, `2606:4700:4700::1003`	`https://family.cloudflare-dns.com/dns-query`	`family.cloudflare-dns.com`

Points d'exploitation à connaître :

Do53 (UDP/TCP 53) : vous mettez des IP (ex: 1.1.1.1) dans vos paramètres réseau/DHCP.
DoT/DoH : vous devez configurer un client compatible (OS, navigateur, proxy DNS sur routeur, relai DNS local, etc.).
Pour DoH, privilégiez la configuration par hostname (cloudflare-dns.com) plutôt que "par IP", pour éviter certains incidents anycast (on en parle plus bas).

Confidentialité : ce que 1.1.1.1 promet (et comment le lire en admin)

Le bon cadrage : DoT/DoH chiffrent le transport entre le client et le résolveur. Mais le résolveur voit toujours les domaines demandés (sinon il ne peut pas répondre). Donc, au final, vous choisissez surtout à qui vous confiez votre DNS et comment vous protégez le dernier kilomètre.

Cloudflare documente ses engagements de confidentialité pour le résolveur 1.1.1.1, notamment :

pas de vente/partage de données personnelles des utilisateurs du résolveur à des tiers, et pas d'usage publicitaire,
limitation de la conservation (suppression des logs de résolveur sous ~25 heures),
non-conservation de l'IP source en "stockage non volatile", avec anonymisation/troncature,
un échantillonnage très faible de paquets réseau pour troubleshooting/mitigation DoS,
un partage limité de données agrégées avec APNIC pour des objectifs de recherche.

Traduction opérationnelle :

Si vous cherchez surtout à éviter l'observation locale (Wi‑Fi, FAI, réseau invité) : activez DoT/DoH.
Si votre sujet est "minimiser l'empreinte côté fournisseur" : lisez la politique de rétention et demandez-vous si vous préférez un fournisseur "logs courts" (Cloudflare) vs "pas d'IP du tout" (ex: Quad9) vs un acteur qui garde des logs temporaires plus longs (ex: Google).
Si votre sujet est la conformité : ne mélangez pas "DNS public" et "DNS d'entreprise". Pour des politiques (catégories, exceptions, logs, analytics), vous voudrez souvent un DNS managé (Zero Trust / DNS gateway) ou un résolveur interne.

Do53, DoT, DoH, ODoH : choisir le bon transport

Raccourci utile : changer de résolveur (1.1.1.1 vs DNS FAI) n'implique pas automatiquement chiffrer le DNS.

Do53 (DNS classique)

Ports : UDP/53 (principalement), parfois TCP/53.
Avantage : universel, simple (routeur/DHCP).
Limites : lisible/interceptable sur le réseau ; certains environnements réécrivent le DNS.

DoT (DNS-over-TLS)

Port : TCP/853.
Avantage : DNS chiffré, souvent supporté nativement au niveau OS (Android "DNS privé", systemd-resolved, certains routeurs).
Limites : port 853 parfois filtré.

DoH (DNS-over-HTTPS)

Port : HTTPS 443.
Avantage : plus difficile à bloquer (c'est du HTTPS), bon sur des réseaux "hostiles".
Limites : côté parc, vous devez savoir qui fait du DoH (navigateurs, agents, proxy DNS...), sinon vous perdez la maîtrise du chemin DNS.

ODoH (Oblivious DoH)

Idée : séparer "qui demande" (IP source) de "quoi est demandé" (nom de domaine) via un proxy.
Avantage : réduit la capacité d'un acteur unique à lier IP ↔ requêtes.
Limites : ce n'est pas encore un "standard universel" en entreprise ; support client plus rare ; à traiter comme une option avancée.

Choisir Do53 / DoT / DoH / ODoH selon vos contraintes réseau

Actualité 2025 : la panne globale 1.1.1.1 et la leçon à retenir

Le 14 juillet 2025, Cloudflare a subi une panne globale de son résolveur 1.1.1.1 (environ 62 minutes). Dans ce type d'incident, l'effet ressenti côté utilisateurs est brutal : "Internet est cassé", car plus rien ne résout.

Point intéressant du post-mortem : le trafic DoH est resté plus stable, car beaucoup de clients DoH utilisent le nom de domaine cloudflare-dns.com (donc une autre surface d'adressage/anycast) plutôt que la résolution DoH "par IP".

La conclusion "admin" n'est pas de fuir 1.1.1.1, mais de l'intégrer correctement :

ne pas dépendre d'un seul résolveur,
ajouter une stratégie de secours,
observer et tester régulièrement.

Déploiement en PME : 3 modèles qui marchent (et leurs pièges)

Modèle 1 : Routeur/DHCP (rapide, mais souvent en clair)

Objectif : tout le LAN bascule sans toucher chaque machine.

Configurez le DNS LAN sur 1.1.1.1 et 1.0.0.1 (et les IPv6 si vous en avez).
Gardez en tête : c'est très souvent du Do53 (non chiffré) et certains postes peuvent contourner (DNS statique, DoH navigateur, VPN).

Modèle 2 : Configuration par OS (bon pour DoT/DoH natif)

Cas typiques : laptops nomades, serveurs critiques, parc mobile.

Exemples concrets :

Android 9+ (DoT via "DNS privé") : définissez le fournisseur sur one.one.one.one (ou security.cloudflare-dns.com / family.cloudflare-dns.com selon le besoin).
Navigateurs (DoH) : utile en mobilité, mais attention : ça peut court-circuiter votre DNS d'entreprise.

Modèle 3 : Relai DNS local (recommandé si vous voulez du chiffré "partout")

Objectif : les postes parlent à un DNS local (cache + contrôle), et ce DNS local parle en DoT/DoH vers 1.1.1.1.

Avantages :

chiffrement vers l'extérieur,
cache local (latence perçue réduite),
point de contrôle unique (observabilité, dépannage, bascule).

Exemple minimal avec Unbound en DoT (à adapter) :

# /etc/unbound/unbound.conf.d/cloudflare-1111.conf
forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 1.1.1.1@853#one.one.one.one
  forward-addr: 1.0.0.1@853#one.one.one.one

Et côté poste, vous pointez vers votre relai DNS (ex: 10.0.0.53) au lieu de pointer directement vers 1.1.1.1.

Architecture recommandée : cache local + secours

Tester vraiment que vous utilisez 1.1.1.1 et le bon protocole

Test 1 : Vérifier côté Cloudflare

Cloudflare fournit une page de diagnostic : ouvrez https://1.1.1.1/help depuis un poste du réseau. Elle indique si vous êtes connecté à 1.1.1.1 et si vous utilisez DoH/DoT.

Test 2 : Tester une résolution simple

dig @1.1.1.1 cloudflare.com A +tries=1 +time=2
dig @1.0.0.1 cloudflare.com AAAA +tries=1 +time=2

Test 3 : Tester DoH en ligne de commande

curl -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

Plan d'action (prêt pour la prod)

Inventaire : où est défini le DNS aujourd'hui (DHCP, statique, VPN, navigateurs, agents) ?
Choix de l'objectif : confidentialité du dernier km (DoT/DoH), filtrage simple (Families), ou contrôle fin (DNS gateway/solution managée).
Choix du modèle : routeur/DHCP (vite), OS (nomades), relai DNS local (robuste).
Activer le chiffrement là où ça compte : au minimum sur les postes nomades et/ou via relai DNS.
Mettre un plan de secours : second résolveur, ou au minimum un cache local + bascule documentée.
Tests : 1.1.1.1/help, dig, et un test DoH/DoT selon votre outillage.
Observabilité : surveillez taux de SERVFAIL/NXDOMAIN, latence, timeouts, et incidents.

FAQ

1.1.1.1 est-il vraiment plus privé que le DNS de mon FAI ?

Oui, dans la pratique, surtout si vous activez DoT/DoH : vous évitez l'observation et l'interception sur le réseau local et chez le FAI. Mais vous confiez alors vos requêtes à Cloudflare : l'enjeu devient la politique de logs et la confiance dans le fournisseur.

DoH ou DoT : lequel choisir en entreprise ?

Choisissez DoT si vous maîtrisez le réseau (port 853 autorisé) et que vous voulez une implémentation "DNS pure". Choisissez DoH si vous êtes souvent sur des réseaux filtrants (hôtels, Wi‑Fi publics) ou si vous avez besoin de passer en 443.

DoH côté navigateur : bonne idée ou piège ?

Bonne idée en mobilité (réseau non fiable), mais piège en entreprise : le navigateur peut contourner votre DNS interne (split-horizon, domaines internes, politiques). Si vous avez un DNS d'entreprise, définissez une politique claire (autoriser, forcer via proxy DNS, ou désactiver).

Pourquoi ajouter un DNS secondaire si 1.1.1.1 est anycast ?

Parce que l'anycast n'élimine pas les pannes globales, et qu'un incident DNS ressemble à une panne Internet. Le bon compromis : un cache/relai DNS local + un ou deux résolveurs amont, et une bascule documentée.

ODoH, c'est pour moi ?

Si vous avez déjà une pile DNS avancée et un besoin fort de dissocier IP ↔ requêtes (cas sensibles), ça peut valoir un POC. Sinon, DoT/DoH + une politique de logs claire apporte déjà 80% du bénéfice avec beaucoup moins de complexité.

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 DNS (récursif) : serveur qui résout un nom de domaine en IP en interrogeant la racine, les TLD et les serveurs autoritatifs, puis met en cache.
Do53 : DNS "classique" en clair sur UDP/TCP port 53.
DoT : DNS-over-TLS, DNS chiffré sur TCP/853.
DoH : DNS-over-HTTPS, DNS chiffré sur HTTPS/443.
ODoH : Oblivious DoH, variante qui ajoute un proxy pour dissocier IP source et contenu de la requête.
Anycast : routage qui envoie le trafic vers le point de présence "le plus proche" (au sens du routage), utilisé par les grands résolveurs.
NXDOMAIN : réponse DNS indiquant qu'un nom n'existe pas.
SERVFAIL : échec de résolution (amont indisponible, validation, timeouts, etc.).