Comment fonctionne réellement le filtrage DNS — et les quatre limites que les éditeurs n'affichent pas

En résumé : lorsqu'une application de votre téléphone tente de se connecter à analytics.facebook.com, elle doit d'abord résoudre l'adresse IP de ce nom d'hôte via DNS. Un résolveur DNS filtrant intercepte cette requête, reconnaît la destination comme un traqueur, et refuse de retourner une adresse IP. La connexion n'est jamais établie ; les données ne quittent jamais votre appareil. C'est élégant et puissant — mais cela comporte quatre limites que toute discussion honnête doit mentionner : il ne peut pas voir le contenu du trafic chiffré, il ne peut pas filtrer les publicités servies depuis le même domaine que le contenu légitime, certaines applications contournent entièrement le DNS système, et les protocoles DNS chiffrés (DoH/DoT/ECH) font évoluer l'observabilité des réseaux. Ci-dessous : le mécanisme, puis chaque limite, puis là où le filtrage DNS reste gagnant.

Le mécanisme en cinq étapes

Chaque connexion réseau effectuée par votre téléphone suit cette séquence (que vous le remarquiez ou non) :

Une application souhaite joindre un serveur. Instagram veut charger une story ; le SDK Facebook veut envoyer une empreinte numérique ; Safari ouvre une page web. Tout cela commence par un nom d'hôte — graph.facebook.com, cdn-news.com, www.example.com.
Le système d'exploitation demande l'adresse IP au DNS. Les ordinateurs ne communiquent pas directement avec graph.facebook.com — ils communiquent avec 157.240.22.174. Le DNS est l'annuaire qui traduit les noms d'hôtes en adresses IP.
La requête DNS est transmise à un résolveur. Sans VPN, il s'agit généralement du résolveur de votre FAI ou du DNS que vous avez configuré (souvent le 8.8.8.8 de Google ou le 1.1.1.1 de Cloudflare). Avec Casper ou un autre outil de filtrage DNS, la requête est acheminée vers notre résolveur, via le tunnel chiffré.
Le résolveur filtrant évalue la destination. graph.facebook.com figure-t-il sur la liste de blocage des traqueurs ? Sur une classification ML de domaine de phishing ? Sur une liste blanche personnalisée de l'utilisateur ? Cette évaluation s'effectue en quelques millisecondes.
Le résolveur retourne une réponse — ou refuse. Pour les domaines légitimes : une vraie adresse IP, l'application se connecte, tout se passe normalement. Pour les domaines bloqués : une réponse « NXDOMAIN » ou 0.0.0.0, la tentative de connexion échoue, et les données ne quittent jamais votre appareil.

Voilà tout le mécanisme. Pas de DPI sur l'appareil, pas de hooks noyau, pas de tour de passe-passe avec injection de certificat. Ça fonctionne parce que chaque connexion IP doit commencer par une résolution de nom d'hôte, et cette résolution est un texte en clair non chiffré que le résolveur contrôle. Refuser la résolution, c'est refuser la connexion.

Pourquoi cette approche offre un levier inhabituel

Trois caractéristiques structurelles rendent le filtrage DNS particulièrement efficace :

Il est agnostique aux applications. Les extensions de navigateur ne protègent que le navigateur dans lequel elles s'exécutent. Les bloqueurs de contenu Safari ne protègent que Safari. Le filtre DNS de Casper protège Instagram, l'application YouTube, votre widget météo, votre application de streaming sur TV connectée, Mail, Slack, chaque utilitaire de la barre de menus sur Mac — tout ce qui effectue une résolution DNS.
Il est agnostique aux protocoles. HTTP, HTTPS, WebSockets, protocoles binaires personnalisés — tout ce qui commence par une résolution DNS est filtré. La couche de chiffrement au-dessus n'a pas d'importance ; le résolveur intervient avant le début de la négociation de chiffrement.
Il est centralisé. Chaque appareil de votre compte bénéficie de la même protection à partir d'une seule mise à jour de configuration. Pas besoin de gérer une flotte d'extensions de navigateur.

C'est pourquoi les outils de filtrage DNS (Pi-hole, NextDNS, AdGuard DNS, et notre propre Casper) sont devenus le modèle dominant en matière de filtrage de la confidentialité des consommateurs au cours des cinq dernières années. Mais ce levier fonctionne dans les deux sens — quand le filtrage DNS échoue, il a tendance à échouer silencieusement et à grande échelle.

Limite 1 — Il ne peut pas voir ce qui se passe à l'intérieur du trafic chiffré

Le filtrage DNS opère sur les noms d'hôtes, pas sur les URL ni sur les charges utiles. Si un domaine est entièrement bloqué, chaque page et chaque point de terminaison de ce domaine est bloqué. Si un domaine est entièrement autorisé, chaque page et chaque point de terminaison est autorisé. Il n'y a pas de demi-mesure au niveau DNS — une fois l'adresse IP résolue, le résolveur n'a plus aucune visibilité sur ce que fait l'application ensuite.

Ce n'est pas un problème pour la plupart des infrastructures de suivi, qui utilisent des sous-domaines dédiés : analytics.facebook.com, tag-manager.google.com, events.amplitude.com. Bloquer le sous-domaine laisse le site hôte fonctionner et neutralise l'analytique. Mais c'est un problème difficile lorsque les publicités ou les traqueurs partagent le même domaine que le contenu légitime — Instagram sert à la fois du contenu et des publications sponsorisées depuis l'infrastructure de Meta ; YouTube sert des vidéos et des publicités pre-roll depuis googlevideo.com ; X sert des tweets sponsorisés depuis les mêmes noms d'hôtes que votre fil d'actualité. Le filtrage DNS ne peut pas les distinguer.

Ce que cela signifie en pratique : Casper élimine environ 80 à 90 % des publicités et des traqueurs que vous rencontrez en une semaine typique sur un téléphone typique. Les 10 à 20 % restants sont hébergés en première partie et nécessitent une intervention différente — généralement une extension de navigateur au niveau du rendu DOM (uBlock Origin dans Chrome / Firefox, Brave Shields intégré, l'extension Safari d'AdGuard) capable de voir la page rendue et de masquer des éléments spécifiques. Nous recommandons explicitement d'utiliser les deux couches pour une couverture maximale ; Casper couvre la couche réseau que les extensions de navigateur manquent, et les extensions de navigateur couvrent la couche DOM que le DNS manque.

Limite 2 — Certaines applications contournent entièrement le DNS système

Un nombre croissant d'applications n'utilisent plus le résolveur DNS système — elles embarquent leurs propres implémentations DNS-over-HTTPS (DoH) ou DNS-over-TLS (DoT) qui communiquent directement avec Cloudflare, Google ou l'infrastructure du développeur, contournant ainsi le DNS configuré par l'utilisateur.

Firefox le fait par défaut (programme Trusted Recursive Resolver de Mozilla). Chrome le fait lorsque le résolveur DNS existant de l'utilisateur figure sur la liste de détection automatique de Google. Certaines applications Android populaires (Brave, Discord, Signal, plusieurs applications de streaming) embarquent des points de terminaison DoH codés en dur. La motivation est généralement la confidentialité — empêcher la surveillance DNS au niveau du FAI — mais l'effet secondaire est que le filtrage DNS configuré par l'utilisateur ne s'applique pas à ces applications.

Ce que cela signifie en pratique : sur iOS, ce phénomène est rare et le framework NetworkExtension d'Apple donne à Casper suffisamment d'accroches pour intercepter la plupart des tentatives de DoH au niveau des applications. Sur Android, la situation est plus complexe — certaines applications résoudront des noms d'hôtes hors de notre visibilité. La réponse de Casper est double : (a) nous publions une liste des applications dont le comportement de contournement DoH est connu, afin que les utilisateurs sachent ce qui échappe au filtre, et (b) sur Android, nous utilisons le routage VPN par application pour forcer le trafic critique vers le chemin DNS système pour les applications où vous souhaitez spécifiquement que le filtrage soit appliqué. C'est l'un des rares cas où l'architecture VPN plus flexible d'Android est un véritable avantage sur iOS.

Limite 3 — Les CDN et infrastructures partagées rendent le blocage par locataire impossible

De nombreux sites web et services partagent des noms d'hôtes au niveau IP — cdn-namespace.cloudfront.net peut servir du contenu pour des milliers d'organisations différentes derrière le même point de terminaison Cloudfront. Bloquer le nom d'hôte bloque tous ceux qui le partagent ; l'autoriser les autorise tous. Le résolveur DNS n'a aucun moyen de savoir quel locataire est destinataire d'une requête spécifique.

Le cas le plus courant où cela pose problème : bloquer les points de terminaison de suivi de Google tout en autorisant ses points de terminaison fonctionnels. googletagmanager.com est purement du suivi et peut être bloqué sans risque. Mais googleapis.com héberge tout, des tuiles Maps au Cloud Storage en passant par Firebase Auth, aux côtés de l'ingestion Analytics — le bloquer casserait une grande partie des applications. La liste de blocage par défaut de Casper est calibrée pour laisser ouverts les points de terminaison fonctionnels partagés tout en bloquant les points de terminaison dédiés au suivi, mais il y a un plafond dur à la granularité atteignable sans casser des applications.

Ce que cela signifie en pratique : certains signaux de suivi passent parce que le nom d'hôte sous-jacent est trop imbriqué dans des fonctionnalités légitimes pour être bloqué. Nous détaillons les principaux cas dans notre documentation d'assistance afin que vous sachiez ce qui passe à travers. Pour les utilisateurs qui souhaitent un blocage plus strict en acceptant que certaines applications se cassent, un préréglage « agressif » est disponible.

Limite 4 — Encrypted Client Hello (ECH) fait évoluer l'observabilité

La négociation TLS a historiquement laissé fuiter le nom d'hôte de destination via le champ Server Name Indication (SNI) — même lorsque le DNS était chiffré, un observateur sur le réseau pouvait voir les sites auxquels vous vous connectiez. Le standard Encrypted Client Hello (ECH) de l'IETF chiffre cette dernière pièce, et il se déploie largement en 2025–2026 (Cloudflare l'a activé par défaut fin 2024, Firefox le prend en charge de manière stable, Chrome est en déploiement progressif).

Pour la confidentialité, c'est vraiment une bonne chose — votre FAI ne peut plus voir les sites que vous visitez, même au niveau TLS. Pour le filtrage DNS, cela ne change rien directement : nous opérons sur la résolution DNS elle-même, pas sur l'observation TLS. Mais ECH s'inscrit dans une tendance plus large vers un DNS plus chiffré (DoH/DoT/ODoH/Oblivious DNS) où les utilisateurs délèguent la fonction de résolveur à des tiers, parfois sans s'en rendre compte. Cette délégation peut contourner les outils de filtrage configurés par l'utilisateur.

Ce que cela signifie en pratique : la pile de confidentialité des consommateurs se fragmente. iCloud Private Relay d'Apple achemine le trafic chiffré via les résolveurs d'Apple (contournant le DNS utilisateur). Le DoH par défaut dans certains navigateurs fait de même. ECH est bénéfique pour la confidentialité vis-à-vis des observateurs passifs, mais réduit l'autonomie des utilisateurs sur leur propre trafic. La réponse de Casper est de fournir la visibilité au niveau réseau que les utilisateurs souhaitent, là où ils la veulent réellement (leur propre résolveur filtrant), et de s'intégrer aux tendances générales de chiffrement — plutôt que de leur résister.

Là où le filtrage DNS reste gagnant

Nommer les limites ne signifie pas que le filtrage DNS est un mauvais choix — cela signifie simplement une discussion honnête. Les cas où il reste l'intervention la plus propre :

Le suivi comportemental par les SDK embarqués. Facebook SDK, Mixpanel, Amplitude, Segment, AppsFlyer — tous utilisent des noms d'hôtes de traqueurs dédiés que le filtrage DNS bloque nettement. C'est la plus grande catégorie par volume et celle que les utilisateurs veulent le plus bloquer. Le blocage de traqueurs de Casper couvre cela directement.
Les réseaux publicitaires dans toutes les applications. DoubleClick, AdMob, les principaux points de terminaison d'ingestion des réseaux publicitaires utilisent tous des noms d'hôtes dédiés. Les bloquer réduit au silence les publicités dans la longue traîne des applications mobiles où les extensions de navigateur ne fonctionnent pas. Voir comment cela se traduit en pratique.
Les domaines de phishing et de malware. L'évaluation des menaces en temps réel au niveau DNS détecte les domaines de phishing zero-day avant qu'ils soient ajoutés aux listes de blocage publiques. C'est là que le classificateur IA de la protection contre les menaces de Casper fait ses preuves — détaillé dans notre analyse de trois vraies campagnes de phishing.
L'exfiltration d'empreintes numériques entre applications. Même lorsqu'iOS App Tracking Transparency bloque l'IDFA, les applications continuent d'exfiltrer des données d'empreinte — mais elles doivent les envoyer quelque part. La couche DNS intercepte l'exfiltration quel que soit l'identifiant que l'application aurait utilisé. Voir notre analyse approfondie de ce qu'ATT ne bloque pas.
La télémétrie des OEM et des systèmes d'exploitation. Samsung Knox Analytics, Xiaomi cloud, les points de terminaison d'analytique d'Apple, la télémétrie Windows — tous utilisent des noms d'hôtes dédiés que le filtrage DNS bloque sans casser les parties fonctionnelles du système d'exploitation.
La protection sur les réseaux hostiles (WiFi public). Le tunnel VPN qui transporte le trafic DNS chiffre également tout ce qui transite sur le réseau local — ainsi, même lorsque le bénéfice du filtrage DNS est faible, le bénéfice du chiffrement sur le WiFi d'un café est bien réel.

Le modèle à deux couches qui fonctionne vraiment

Pour les utilisateurs qui souhaitent la protection la plus complète, le schéma qui fonctionne le mieux est deux couches complémentaires :

Couche réseau (filtre DNS) : couvre chaque application sur l'appareil, bloque les 80 à 90 % du trafic traqueur/publicitaire/phishing qui utilise des noms d'hôtes dédiés. Casper opère ici.
Couche DOM (bloqueur de contenu dans le navigateur) : uBlock Origin dans Chrome / Firefox, Brave Shields intégré, ou l'extension Safari d'AdGuard. Intercepte les publicités hébergées en première partie sur Instagram, YouTube, X, et autres que le DNS ne peut pas distinguer du contenu légitime.

Chaque couche couvre les lacunes que l'autre ne peut pas combler. Ensemble, elles atteignent plus de 95 % de couverture ; chacune seule est plutôt à 80 %. La plupart des utilisateurs soucieux de leur confidentialité avec qui nous avons parlé utilisent exactement cette combinaison.

En résumé

Le filtrage DNS est le bon endroit pour intervenir sur la plus grande partie des menaces à la confidentialité des consommateurs — suivi par SDK embarqué, exfiltration par les réseaux publicitaires, résolution de domaines de phishing, télémétrie des OEM. Ce n'est pas de la magie, et cela ne couvre pas tous les cas. Les quatre limites évoquées ci-dessus sont réelles, et tout éditeur qui les dissimule vend mal son produit ou vend quelque chose qu'il ne devrait pas. Combinez la couche réseau avec une couche DOM dans le navigateur pour les cas résiduels, considérez le chiffrement sur réseau hostile comme un avantage supplémentaire inclus, et vous couvrirez l'essentiel de ce à quoi ressemble la surface de menace pour un consommateur en 2026.