Filtre DNS du VPN : bloquer des noms ne bloque pas les publicités

Une seule ligne dnsmasq peut répondre à un nom par NXDOMAIN, et c’est tout le mécanisme. Elle ne lit jamais le HTML, n’inspecte jamais le chemin d’une requête et ne voit jamais ce qu’une application fait d’une connexion qu’elle a déjà ouverte. La comparer à une extension de navigateur revient donc à comparer deux tâches différentes. L’une décide si un nom se résout ; l’autre décide de ce qui se passe ensuite.

Ce qu’un filtre de noms contrôle réellement

L’option address=/metrics.example/, sans rien après la dernière barre oblique, fait renvoyer NXDOMAIN par le résolveur pour ce nom et ses sous-domaines. Laisser l’adresse vide est la partie importante : cela évite d’envoyer les clients vers un serveur de remplacement sans rapport ou de faire passer une adresse de bouclage pour la destination réelle. Le manuel de dnsmasq décrit cette forme comme une réponse négative et non comme une redirection.

Tout ce que la règle peut faire découle de cette unique décision. Un client qui interroge ce résolveur obtient une réponse négative ; un client qui interroge un autre résolveur obtient ce que ce résolveur dit. Le filtre ne sait rien du chemin, de la chaîne de requête ni du compte que l’application aurait utilisé.

Cette granularité compte parce qu’un nom d’hôte sert souvent à plusieurs usages. Les points de connexion, les images et le suivi peuvent partager un domaine, et une règle qui supprime tout le nom peut supprimer aussi un flux de travail. Une politique au niveau du nom doit accepter ce compromis ou choisir des noms plus étroits.

En quoi un bloqueur côté client diffère

Une extension de navigateur voit la requête avant qu’elle parte, elle peut donc faire correspondre un chemin d’URL, annuler une requête précise et masquer l’élément qui aurait affiché le résultat. Elle peut autoriser example.com/article tout en refusant example.com/ads/, ce qu’aucune réponse DNS ne peut exprimer. Cette vue au niveau du chemin est la capacité qu’un résolveur n’a tout simplement pas. C’est aussi pourquoi une liste de filtres conçue pour un outil se comporte rarement de la même façon dans l’autre.

Le prix est la portée. Cette protection vit dans un navigateur, dans un profil, sur un appareil, et elle disparaît lorsque l’utilisateur passe à une autre application. Un filtre DNS configuré sur la passerelle couvre chaque appareil qui utilise le résolveur de la passerelle, y compris ceux où aucune extension ne peut être installée.

Aucune des deux dispositions n’est complète à elle seule. Un filtre DNS ne peut pas retirer un identifiant qu’une page a déjà envoyé, et une extension de navigateur ne peut pas protéger une application qui ne la charge jamais.

Le chemin du résolveur décide si tout cela s’applique

Un VPN peut annoncer un serveur DNS et ne pas recevoir toutes les requêtes pour autant. Un navigateur configuré avec un DNS chiffré, une application dotée de son propre résolveur ou un appareil sur un chemin réseau qui exclut la passerelle iront tous chercher ailleurs. Les plateformes mobiles proposent de plus en plus un réglage de DNS privé qui écrase discrètement ce que le tunnel suggère.

Testez donc le chemin plutôt que la politique. Interrogez le résolveur prévu directement depuis la passerelle, interrogez-le ensuite depuis un client et comparez, puis observez si un nom qui devrait être bloqué échoue réellement dans l’application que l’utilisateur exécute.

Les réponses en cache et les sockets ouverts rendent cela bruyant. Une page qui a déjà chargé ses ressources continuera de fonctionner après le changement de règle, donc une connexion neuve est un meilleur test que le rechargement d’un ancien onglet.

Testez les deux sens avant d’annoncer un résultat

Utilisez un nom de documentation bloqué exprès, un nom public autorisé et un nom privé dont le service a besoin :

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

Une réponse vide pour le nom bloqué, une adresse normale pour le public et une adresse privée pour l’interne montrent ensemble que le filtrage, la résolution en amont et les enregistrements locaux fonctionnent. Si les trois échouent, vous êtes face à un problème en amont ou au niveau de l’écouteur, pas à un filtre.

Gardez l’affirmation étroite dans tout ce que vous publiez en interne. Il s’agit d’un filtrage de domaines sur un résolveur, non d’une inspection de contenu, non d’un filtrage de chemins et non d’une promesse que personne n’est suivi. Indiquez le propriétaire de la politique, la route d’exception et la durée de conservation des requêtes à côté des règles, car un filtre qui journalise chaque recherche a son propre coût pour la vie privée.