Vous pointez le téléviseur vers un résolveur Smart DNS, une application de streaming se met à fonctionner, et la conclusion s'écrit d'elle-même : c'est un VPN qui coûte moins cher et s'installe plus vite. Ce n'en est pas un, et l'écart n'est pas de la pédanterie. Ce qui a changé, c'est la réponse que le téléviseur a reçue quand il a demandé où réside un nom d'hôte ; ce qui n'a pas changé, c'est que chaque paquet quitte toujours votre maison en clair, sur le même chemin, depuis la même adresse que le fournisseur connaît déjà. Le mythe est qu'un réglage DNS est un tunnel. La réalité est plus étroite et plus utile dès que vous la voyez.

Le mythe : un changement de DNS réachemine votre trafic

Le DNS ordinaire indique à une application où se connecter. Un service Smart DNS répond à des noms d'hôtes choisis avec des adresses qui appartiennent à l'infrastructure du fournisseur, si bien que l'application s'y connecte au lieu du service directement. Le fournisseur relaie ensuite ce seul flux vers la destination réelle. Rien d'autre sur l'appareil ne bouge.

C'est pourquoi l'astuce fonctionne sur un téléviseur ou une console. Il n'y a pas de client, pas d'interface, pas d'entrée dans la table de routage, pas de couche de chiffrement. L'appareil fait exactement ce qu'il a toujours fait : résoudre un nom et se connecter à ce qui revient. Vous avez changé la réponse, pas le chemin de chaque paquet.

L'étiquette est aussi utilisée par des projets DNS sans rapport, alors consultez la documentation du fournisseur plutôt que de déduire un ensemble de fonctions du nom. Il n'existe pas de protocole Smart DNS standard ; la couverture d'un produit ne dit rien de fiable sur un autre.

Ce qui est réellement orienté, et ce qui ne l'est pas

La distinction est facile à voir dès que vous la listez par flux plutôt que par appareil.

FlowSteered by Smart DNS?Why
A supported streaming hostnameYes, usuallyThe resolver returns a provider address for that name
The same app's other hostnamesOnly if the provider lists themSteering is per-name, and lists are curated
Your browser, email, game downloadsNoTheir names resolve to the ordinary destination
Traffic from devices not using that resolverNoNothing forces a device onto a particular resolver
Payload encryptionNoUnrelated to name resolution

Vous pouvez le constater. Interrogez le résolveur du fournisseur sur un nom d'hôte et un résolveur public sur le même :

dig +short @<provider-resolver> example-stream.example
dig +short @1.1.1.1 example-stream.example

Des réponses différentes signifient une orientation au niveau du nom. La même réponse signifie soit que le service ne couvre pas ce nom, soit que l'appareil n'utilise pas ce résolveur — une panne qui ressemble à une mauvaise configuration DNS et qu'on prend souvent pour un compte cassé.

Il existe une seconde panne avec la même odeur. Beaucoup de fournisseurs autorisent selon l'adresse publique que vous utilisez en ce moment, donc le compte fonctionne jusqu'à ce que l'adresse change. La rotation NAT d'opérateur, ou un VPN par-dessus, déplace cette adresse et le relais vous refuse, tandis que la résolution continue de réussir. L'entrée au registre est un contrôle d'accès, pas la preuve d'une sortie exclusive.

Le DNS chiffré est une troisième chose tout à fait

DNS sur HTTPS et DNS sur TLS protègent l'échange entre votre appareil et le résolveur. Ils chiffrent et authentifient la requête pour que le réseau local ne puisse ni la lire ni la réécrire, et DoH la transporte dans du trafic HTTPS ordinaire sur le port 443, ce qui explique aussi qu'elle ressemble à du trafic web pour un filtre. C'est une fonction de confidentialité des requêtes.

Orienter un service est une autre fonction : la réponse elle-même désigne un intermédiaire. Un produit peut proposer les deux à la fois, et beaucoup le font, mais l'un n'implique pas l'autre. Chiffrer vos requêtes n'a jamais fait passer un seul octet de vidéo par un autre pays.

Donc « DNS chiffré » répond à une question sur qui peut lire vos requêtes. Il ne répond pas à qui peut voir votre trafic, et il ne vous donne pas une nouvelle adresse de sortie. La spécification de DNS over HTTPS est la bonne référence pour ce que couvre cette protection, et elle ne dit rien sur le routage.

Qui voit quoi dans chaque dispositif

Avec Smart DNS, le résolveur voit les noms que vous interrogez, le relais du fournisseur voit les connexions qu'il transporte, et votre fournisseur d'accès voit toujours tout le reste en structure de texte ouvert : quelles adresses vous avez contactées, quand et combien. Le contenu reste protégé par TLS jusqu'à la destination dans le flux orienté, donc le relais transmet une session chiffrée qu'il ne peut pas lire — mais il peut voir que vous vous êtes connecté, d'où et pendant combien de temps.

Avec un VPN, l'opérateur du tunnel voit votre trafic et vos destinations, ce qui est une seule décision de confiance concentrée, et votre fournisseur d'accès ne voit qu'un flux chiffré vers un seul point de sortie. Une exposition différente, pas automatiquement moindre. Aucun des deux modèles ne devrait être jugé sur l'ouverture d'un site.

La vitesse suit le chemin, pas l'étiquette. Un relais sélectif peut garder le trafic sans rapport hors d'un détour, ce qui est un vrai avantage pour un appareil qui, sinon, tunneliserait tout. Ce n'est pas non plus une garantie, et aucun dispositif ne promet un accès permanent à un service qui cherche activement à le détecter.

Quand Smart DNS est le bon outil

C'est vraiment le bon outil quand l'appareil ne peut pas exécuter de client VPN du tout — un téléviseur, une console, un boîtier décodeur avec une pile réseau verrouillée — et quand seul un service nommé compte. C'est aussi raisonnable quand vous ne voulez délibérément pas que chaque paquet de cet appareil soit tunnelisé.

C'est le mauvais outil quand l'exigence est le chiffrement, une adresse de sortie pour tout l'appareil ou une protection contre le réseau local et le fournisseur d'accès. Ce sont des propriétés de tunnel, et aucun réglage de résolveur ne les produit. Et si vous gardez un VPN sur le même appareil, attendez-vous à ce que l'autorisation fondée sur l'enregistrement casse, car votre adresse publique est désormais celle du tunnel.

Parcourez cette décision dans l'ordre et arrêtez-vous à la première ligne qui est vraie :

  • Avez-vous besoin du trafic chiffré et de tout l'appareil sur une nouvelle sortie ? Utilisez un VPN, et vérifiez ses routes et exclusions plutôt que son indicateur de connexion.
  • N'avez-vous besoin que de quelques services nommés sur un appareil qui ne peut pas tunneliser ? Smart DNS est proportionné.
  • Avez-vous besoin de requêtes privées sans déplacer votre trafic ? C'est le DNS chiffré, qui n'est ni l'un ni l'autre des précédents.
  • Le fournisseur s'appuie-t-il sur votre adresse actuelle ? Attendez-vous à une rupture à l'instant où elle change.

Articles similaires