Le DNS privé sur Android bloque une bonne partie des pubs et des trackers, sans appli, sans VPN, sans friction. Mais cette efficacité a un périmètre précis que la plupart des articles passent sous silence. Les guides qui circulent donnent l’impression d’une solution universelle : activez dns.adguard.com et le problème est réglé. La réalité est plus sélective. Certaines pubs ne disparaîtront jamais via cette méthode. Certains réseaux vont casser votre configuration sans prévenir. Et le chiffrement que vous activez ne signifie pas ce que vous croyez. Ce que vous lisez ici n’est pas un tutoriel de plus : c’est une lecture honnête de ce que cette fonctionnalité peut faire pour vous, selon votre usage réel.
Ce que le DNS privé fait que les autres solutions ne font pas
La plupart des utilisateurs qui découvrent le DNS privé Android arrivent après avoir testé des bloqueurs classiques et en être ressortis déçus. Ce n’est pas un hasard : ces deux approches n’interviennent pas au même endroit dans la chaîne réseau, et cette différence change tout.
Pourquoi les bloqueurs de pubs en VPN local sont structurellement inférieurs
Les applications comme AdGuard, Blokada ou RethinkDNS fonctionnent en créant un VPN local sur votre appareil. Ce tunnel intercepte le trafic pour analyser et bloquer les requêtes indésirables. Le problème n’est pas leur efficacité de filtrage, qui peut être très bonne, c’est leur architecture. Un VPN local actif en permanence maintient une connexion fictive que le système Android traite comme un service réseau prioritaire. Résultat : consommation batterie accrue, conflits avec certains réseaux d’entreprise qui détectent et bloquent les VPN, et incompatibilité fréquente avec d’autres VPN que vous pourriez vouloir utiliser simultanément. Vous ne pouvez pas faire tourner deux VPN en parallèle sur Android sans configuration avancée.
Le DNS privé natif Android n’utilise pas de VPN. Il s’appuie sur le protocole DNS over TLS directement intégré dans la couche réseau du système. Aucun service supplémentaire ne tourne, aucune interface virtuelle n’est créée. C’est une instruction donnée au système : « pour résoudre les noms de domaine, passe par ce serveur précis, de façon chiffrée ». La consommation est négligeable, la compatibilité quasi-totale.
Le filtrage au niveau système : ce que ça signifie concrètement pour les jeux et les apps récalcitrantes
Quand un bloqueur fonctionne en VPN local, il ne voit que le trafic qui passe par son tunnel. Certaines applications, notamment les jeux mobiles et les apps système, peuvent contourner ce tunnel en utilisant des mécanismes réseau différents ou en ayant des exceptions configurées au niveau Android. Le filtrage saute alors, et les pubs passent.
Le DNS privé s’applique en amont, avant même que la requête ne parte vers un quelconque serveur. Quand une app de jeu tente de charger une régie publicitaire, elle commence obligatoirement par résoudre le nom de domaine de cette régie. C’est à ce stade que le DNS filtrant intervient et renvoie une réponse vide ou bloquée. L’application ne peut pas contourner cette étape : la résolution DNS est une opération fondamentale du système, pas un choix de l’app. C’est pourquoi des pubs qui résistaient à AdGuard en VPN local disparaissent avec un DNS privé bien configuré.
Les limites que personne ne mentionne avant que vous l’activiez
Activer le DNS privé sur Android avec AdGuard ou NextDNS réduit effectivement la charge publicitaire de façon perceptible. Mais des catégories entières de pubs et de situations restent hors de portée de cette approche, et aucun guide de configuration n’en parle avant que vous passiez une heure à comprendre pourquoi ça ne fonctionne pas.
YouTube, Twitch, pubs in-app intégrées : le DNS privé est impuissant, voilà pourquoi
La logique du filtrage DNS repose sur une séparation entre le domaine du contenu et le domaine de la publicité. Si les deux sont servis depuis la même infrastructure, il devient impossible de bloquer l’un sans bloquer l’autre.
C’est exactement ce que font YouTube et Twitch. Les pubs pré-roll de YouTube sont délivrées depuis les mêmes serveurs que la vidéo elle-même, sous le même domaine Google. Bloquer googlevideo.com ou youtube.com pour éliminer les pubs revient à bloquer la plateforme entière. Aucun DNS filtrant ne peut résoudre ce problème, et ceux qui prétendent le contraire se contredisent à la première vérification. La seule vraie solution pour YouTube reste un client alternatif comme ReVanced ou un abonnement Premium.
Le même principe s’applique aux pubs intégrées dans certaines apps mobiles : lorsque le SDK publicitaire est compilé directement dans l’application et communique via un domaine générique partagé avec des fonctions légitimes, le DNS ne peut pas distinguer les deux.
Portails captifs, réseaux d’entreprise, apps bancaires : quand le DNS privé casse ce qu’il devrait protéger
Un portail captif, c’est ce que vous voyez quand vous vous connectez au WiFi d’un hôtel ou d’un café et qu’on vous demande d’accepter des conditions avant d’accéder à internet. Ces portails fonctionnent en interceptant vos requêtes DNS non chiffrées pour vous rediriger vers leur page d’authentification. Avec le DNS privé actif, l’interception est impossible : vos requêtes sont chiffrées et partent directement vers votre serveur DNS configuré, qui n’a aucune raison de vous rediriger vers le portail. Vous avez l’impression d’être connecté, mais aucune page ne charge.
Les réseaux d’entreprise avec proxy obligatoire posent le même problème. Certaines apps bancaires, en particulier celles qui embarquent un système de détection de fraude, analysent la configuration réseau de votre appareil et considèrent un DNS personnalisé comme un signal suspect, ce qui peut déclencher un blocage ou forcer une ré-authentification.
La solution dans ces cas est simple mais elle demande de savoir que le problème vient de là : repasser temporairement en mode Automatique dans les paramètres DNS privé.
Chiffrement DNS ≠ anonymat : ce que votre FAI voit encore après activation
C’est peut-être la confusion la plus répandue autour du DNS privé. Beaucoup d’utilisateurs activent cette fonctionnalité avec l’idée que leur FAI ne peut plus surveiller leur navigation. C’est faux, et comprendre pourquoi évite de fausses conclusions sur votre niveau de protection réel.
Le DNS over TLS chiffre uniquement la requête de résolution de nom : personne sur le réseau ne peut intercepter que vous demandez l’adresse IP de tel site. Mais une fois cette adresse obtenue, votre appareil établit une connexion TCP/IP vers cette adresse, et votre FAI voit cette connexion. Il ne sait peut-être plus quel domaine précis vous consultez via les requêtes DNS, mais il voit les adresses IP de destination de tout votre trafic, et par corrélation il peut souvent déduire les services utilisés. En dehors de ça, le SNI (Server Name Indication) présent dans le handshake TLS des connexions HTTPS révèle en clair le nom de domaine de destination, sauf si vous utilisez l’ECH (Encrypted Client Hello), qui n’est pas encore généralisé.
Le DNS privé améliore votre sécurité sur les réseaux publics et réduit la surface d’attaque pour les interceptions DNS. Ce n’est pas un outil d’anonymat.
AdGuard DNS vs NextDNS : le vrai arbitrage, pas la comparaison de features
Opposer ces deux services sur la base de leurs fonctionnalités rate l’essentiel. La vraie question n’est pas « lequel fait plus de choses » mais « lequel colle à votre façon de gérer un outil réseau au quotidien ».
AdGuard DNS sans compte : ce que vous sacrifiez réellement en choisissant la simplicité
AdGuard DNS public (dns.adguard.com) fonctionne sans inscription, sans dashboard, sans configuration. Vous entrez l’adresse, ça filtre. Ce que cette simplicité implique concrètement : vous appliquez les listes de blocage par défaut d’AdGuard, sans pouvoir les ajuster. Si un domaine légitime est bloqué par erreur, vous ne pouvez pas le débloquer sans changer de service. Si vous voulez des listes différentes, plus agressives ou plus permissives, vous ne pouvez pas.
Il existe une version personnalisable d’AdGuard DNS, accessible via adguard-dns.io, qui offre un compte, un tableau de bord et des listes configurables. C’est une offre différente que beaucoup ignorent parce que les guides mentionnent uniquement dns.adguard.com. La version gratuite personnalisée a ses propres limites de requêtes, mais elle change radicalement la proposition par rapport à la version publique statique.
La limite des 300 000 requêtes NextDNS : contrainte réelle ou marketing ?
NextDNS offre 300 000 requêtes mensuelles gratuites, puis bascule en mode passthrough : les requêtes continuent d’être résolues, mais sans filtrage. Ce n’est pas un blocage de service, c’est une dégradation silencieuse qui passe inaperçue si vous ne vérifiez pas vos statistiques.
Sur un seul appareil mobile en usage standard, 300 000 requêtes représentent environ 10 000 requêtes par jour, soit une marge confortable. Le problème arrive quand plusieurs appareils d’un foyer partagent le même profil NextDNS : la limite se consomme vite, et le filtrage disparaît pour tout le monde en milieu de mois sans alerte visible. L’abonnement annuel NextDNS est à 19,90 dollars par an pour des requêtes illimitées, ce qui reste raisonnable, mais la limite gratuite mérite d’être monitorée activement, pas ignorée.
Quel profil choisit lequel, et pourquoi changer d’avis en cours de route est courant
AdGuard DNS public convient si vous voulez une réduction des pubs fonctionnelle immédiatement, sans jamais ouvrir une interface web ni vous soucier de configuration. C’est une solution set-and-forget.
NextDNS s’adresse à ceux qui veulent savoir ce qui est bloqué, débloquer des domaines précis, activer des protections par catégorie (malwares, phishing, tracking agressif) ou gérer un profil enfant avec des restrictions spécifiques. Le gain est réel si vous utilisez le dashboard. Si vous ne l’ouvrez jamais après la configuration initiale, vous payez en complexité pour un résultat similaire à AdGuard.
Ce qui arrive souvent : on commence par AdGuard pour la simplicité, on passe à NextDNS quand on veut débloquer un faux-positif ou comprendre ce qui est filtré, et on reste sur NextDNS une fois le dashboard consulté la première fois.
Configuration sur Android : les étapes que la doc officielle omet
La procédure de base est documentée partout. Ce qui ne l’est pas, c’est l’erreur de paramétrage qui annule silencieusement tout le filtrage, et les étapes de vérification que personne ne précise.
« Automatique » vs nom d’hôte personnalisé : l’erreur qui annule tout le filtrage
Dans les paramètres DNS privé d’Android, trois options existent : Désactivé, Automatique, et Nom d’hôte du fournisseur DNS privé. Le mode Automatique ne fait pas ce que son nom suggère. Il ne choisit pas automatiquement un bon DNS sécurisé. Il indique à Android d’utiliser le DNS over TLS si le serveur DNS assigné par votre réseau le supporte, ce qui dans la pratique signifie que vous utilisez le DNS de votre FAI chiffré. Aucun filtrage, aucun blocage de pubs, aucune protection supplémentaire dans la grande majorité des cas.
Pour que le filtrage fonctionne, la seule option pertinente est « Nom d’hôte du fournisseur DNS privé », dans laquelle vous entrez explicitement l’adresse du service filtrant choisi. C’est l’erreur la plus commune : activer « Automatique » en pensant avoir activé quelque chose d’utile.
Procédure complète AdGuard DNS (dns.adguard.com)
Ouvrez Paramètres, allez dans Réseau et Internet (ou Connexions selon le constructeur), puis dans DNS privé. Sur certains appareils Samsung, le chemin est Connexions > Plus de paramètres de connexion > DNS privé. Sur Xiaomi, cherchez « DNS » dans la barre de recherche des paramètres, le menu est parfois enfoui.
Sélectionnez Nom d’hôte du fournisseur DNS privé. Entrez dns.adguard.com sans « https:// » ni slash final. Appuyez sur Enregistrer. Android affiche immédiatement un indicateur de connexion réussie ou échouée. Si la connexion est indiquée comme valide, le filtrage est actif sur l’ensemble du système, WiFi et données mobiles compris.
Procédure complète NextDNS avec récupération de l’adresse DoT personnalisée
Créez un compte sur nextdns.io. Une fois connecté, rendez-vous dans l’onglet Setup. Vous y trouvez votre identifiant de configuration unique, qui ressemble à une chaîne alphanumérique de six caractères. L’adresse DNS over TLS à utiliser sur Android prend la forme xxxxxx.dns.nextdns.io, où xxxxxx est votre identifiant personnel.
Avant de renseigner cette adresse dans Android, configurez vos listes de blocage dans l’onglet Privacy de votre dashboard NextDNS : ajoutez au minimum NextDNS Ads & Trackers Blocklist et une liste généraliste comme EasyList. Sans cette étape, NextDNS résout vos requêtes de façon sécurisée mais ne bloque rien.
Entrez votre adresse DoT personnalisée dans le champ DNS privé Android de la même façon que pour AdGuard. Après activation, rendez-vous sur test.nextdns.io depuis votre navigateur mobile pour confirmer que votre appareil utilise bien votre profil NextDNS et non un DNS générique.
Vérifier que le DNS privé est actif, et diagnostiquer sans chercher pendant une heure
Android affiche un état de connexion DNS dans les paramètres, mais cet indicateur confirme uniquement que le serveur DNS est joignable, pas que le filtrage fonctionne. Pour vérifier l’efficacité réelle, visitez d3ward.github.io/toolz/adblock depuis votre navigateur mobile : cet outil teste une série de domaines publicitaires connus et indique le pourcentage bloqué.
Si le test échoue alors que la configuration semble correcte, les causes les plus fréquentes sont : le navigateur utilise son propre DNS over HTTPS indépendant du DNS système (Firefox et Brave le font par défaut, désactivez-le dans leurs paramètres réseau), ou votre réseau WiFi actuel bloque le port 853 utilisé par DNS over TLS. Dans ce second cas, testez en passant sur les données mobiles : si le filtrage fonctionne en 4G et pas en WiFi, c’est le réseau local qui pose problème.
Quand désactiver temporairement le DNS privé, et comment le faire sans tout réinitialiser
Désactiver le DNS privé n’implique pas de supprimer votre configuration. L’erreur fréquente est d’appuyer sur Désactivé et de devoir retaper l’adresse du fournisseur lors de la réactivation. Ce n’est pas nécessaire.
Les signaux qui indiquent que c’est le DNS privé le coupable (et pas le réseau)
Deux scénarios sont caractéristiques d’un conflit lié au DNS privé. Premier cas : vous venez de vous connecter à un nouveau réseau WiFi et aucun site ne charge, mais la connexion est indiquée comme active. C’est typiquement un portail captif bloqué. Second cas : une application qui fonctionnait hier affiche subitement des erreurs de connexion ou des écrans blancs, sans mise à jour récente. Une mise à jour côté serveur a pu modifier les domaines utilisés par l’app, et un de ces nouveaux domaines est bloqué par vos listes de filtrage.
La méthode de diagnostic rapide : passez en mode Automatique, testez l’application ou le réseau. Si ça fonctionne immédiatement, le DNS privé était bien en cause. Si le problème persiste en Automatique, cherchez ailleurs.
Basculer en mode Automatique sans perdre sa configuration personnalisée
Retournez dans Paramètres > DNS privé. Choisissez Automatique. Android conserve en mémoire l’adresse du fournisseur que vous avez renseignée dans le champ Nom d’hôte : elle reste présente quand vous revenez sur cette option. Pour réactiver votre configuration personnalisée, resélectionnez simplement Nom d’hôte du fournisseur DNS privé et appuyez sur Enregistrer. Aucune ressaisie n’est nécessaire.
Sur certains appareils sous Android 11 et versions antérieures, ce comportement peut varier et le champ peut apparaître vide à la réouverture. Si c’est le cas, notez votre adresse DNS quelque part avant de basculer.
Questions fréquentes
Le DNS privé Android fonctionne-t-il aussi sur les données mobiles, ou seulement en WiFi ?
Le DNS privé configuré dans les paramètres système Android s’applique à toutes les connexions réseau, WiFi et données mobiles (4G, 5G) sans distinction. Contrairement aux applications VPN qui peuvent avoir des règles différentes selon le type de connexion, le paramètre DNS natif est global. L’exception : certains opérateurs mobiles forcent leur propre DNS via leur APN et peuvent interférer avec DNS over TLS sur port 853. Si le filtrage fonctionne en WiFi mais pas en données mobiles, c’est probablement le cas de votre opérateur.
Peut-on utiliser un DNS privé filtrant et un VPN en même temps sur Android ?
Non, pas simplement. Quand un VPN est actif, tout le trafic DNS passe par le serveur DNS configuré dans le VPN, ce qui court-circuite le paramètre DNS privé Android. Le DNS privé système devient inactif dès qu’un VPN prend le contrôle de la couche réseau. Si vous voulez filtrage et VPN simultanément, la solution est de configurer votre VPN pour qu’il utilise lui-même NextDNS ou AdGuard comme serveur DNS. Certains clients VPN comme Mullvad permettent cette configuration nativement.
Le DNS privé protège-t-il aussi les enfants sur un appareil familial partagé ?
Partiellement. NextDNS propose des profils avec des listes de blocage par catégorie, dont du contenu adulte, et ces blocages s’appliquent à tout le trafic système. Mais ce n’est pas une solution de contrôle parental robuste : n’importe qui qui a accès aux paramètres Android peut désactiver le DNS privé en quelques secondes. Pour une protection enfant sérieuse, combinez le DNS filtrant avec un verrouillage des paramètres réseau via le mode supervision ou une application de contrôle parental qui gère ses propres restrictions.
Est-ce que le DNS privé ralentit la connexion internet ?
Le délai ajouté est théoriquement mesurable, en pratique imperceptible. DNS over TLS ajoute une poignée de millisecondes pour établir la connexion chiffrée, mais Android maintient une connexion persistante avec le serveur DNS, donc ce délai ne se répète pas à chaque requête. Sur des serveurs bien dimensionnés comme NextDNS ou AdGuard, les temps de réponse restent inférieurs à 20ms depuis la France. Aucun utilisateur ne remarquera de différence dans sa navigation quotidienne.
Que se passe-t-il si le serveur DNS privé configuré devient indisponible ?
Android ne bascule pas automatiquement sur un DNS alternatif si le serveur DNS privé configuré est inaccessible. Le système affiche un avertissement « DNS privé indisponible » et la résolution DNS échoue, ce qui empêche toute navigation. Ce comportement est voulu : Android préfère signaler l’indisponibilité plutôt que de revenir silencieusement à un DNS non chiffré. La solution est soit de réactiver temporairement le mode Automatique, soit de patienter que le serveur revienne. NextDNS et AdGuard ont des taux de disponibilité très élevés, mais les pannes ponctuelles existent et ce mécanisme de blocage peut surprendre si on ne l’anticipe pas.
