Un VPN sur DNS n’est pas la même chose qu’un serveur DNS de VPN

Un VPN sur DNS décrit une idée de transport et n’est pas synonyme de pointer un appareil vers un résolveur personnalisé. La question qui tranche la confusion est simple : que transportent réellement les messages DNS ? Un VPN ordinaire peut installer un résolveur pour que les applications couvertes trouvent des noms privés, et changer ce résolveur ne change que la résolution de noms. Exécutez les vérifications ci-dessous dans l’ordre, car les trois dispositifs partagent du vocabulaire et presque rien d’autre.

Séparez les trois dispositifs

Dans le premier dispositif, le VPN fournit un résolveur ou un réglage de politique de noms. Les données des applications circulent toujours par leurs propres connexions réseau, et le tunnel influence seulement quel serveur répond à la requête.

Dans le second, le DNS chiffré protège l’échange DNS lui-même. DNS sur HTTPS et DNS sur TLS enveloppent les requêtes vers le résolveur choisi et ne transportent les paquets d’aucune autre application. Ils ne cachent pas non plus les noms de requête au résolveur que vous avez choisi, ce qui est une frontière de confiance différente de les cacher au réseau local.

Dans le troisième, un client coopératif encode d’autres données dans des messages DNS et un point de terminaison coopératif les reconstruit. Le chemin ordinaire du résolveur devient le transport, et le résolveur est désormais un composant du chemin de données plutôt qu’un service de noms.

Vérifiez ce que transportent les messages DNS

Changez le résolveur et observez si le chemin de trafic de l’application change. Si l’application se connecte encore aux mêmes adresses par les mêmes sockets, vous avez changé la résolution de noms et rien de plus.

Un tunnel transporté par DNS a besoin d’un dispositif correspondant côté serveur. Iodine en est un exemple documenté : sa documentation du projet décrit un tunnel IP à travers DNS, et il exige un composant serveur qui comprenne l’encodage. Saisir une adresse de résolveur public dans Android ne fournit pas ce point de terminaison, et un terme marketing partagé par deux produits n’est pas une spécification de protocole.

La capture est la vérification décisive. Si vous voyez des requêtes ordinaires vers le résolveur et rien d’autre, il n’y a pas de tunnel. Si vous voyez une charge utile encodée dans les noms de requête et les réponses, vous avez trouvé le porteur, et la question suivante est de savoir combien il peut déplacer.

Vérifiez la capacité avant de vous engager

Le DNS a été conçu pour des requêtes et des réponses, pas pour une livraison en masse. La surcharge d’encodage, les limites de taille des messages et le comportement du résolveur prennent tous leur part du chemin nominal, si bien que la capacité utile est inférieure à ce que suggère la liaison sous-jacente. Traitez tout chiffre de débit que vous n’avez pas mesuré sur votre propre chemin comme une hypothèse et non comme un budget. Mesurez les deux directions, car l’envoi et la réception peuvent atteindre des limites différentes sur un porteur de type requête-réponse.

Le client doit aussi décider quel trafic entre dans le tunnel. Une interface locale de service VPN peut collecter des paquets, mais l’interface ne dit rien sur la manière dont le transport distant les protège ou les transfère. La fragmentation et la retransmission se comportent différemment lorsque le porteur est un protocole requête-réponse plutôt qu’un flux, et une connexion qui reste ouverte dit peu de choses sur la latence interactive.

Mesurez avec le trafic que vous comptez transporter. Un tunnel qui semble correct pour un battement périodique peut être inutilisable pour une session interactive, et l’inverse est vrai aussi.

Vérifiez la sécurité du porteur

Ne présumez pas que l’encapsulation DNS fournit la confidentialité ou une authentification forte. Le chemin du résolveur et le point de terminaison du tunnel voient ce que l’implémentation expose, et cette exposition varie selon la conception.

Le chiffrement et le choix du porteur sont des propriétés distinctes. Un tunnel peut être chiffré sur un chemin IP simple, et un tunnel transporté par DNS peut être construit avec ou sans protection de sa charge utile. Maintenez le HTTPS de l’application en place quoi qu’il en soit, et évaluez la conception de sécurité réelle du tunnel plutôt que son nom.

Si l’exigence est la confidentialité vis-à-vis du réseau local, le DNS chiffré et un tunnel de données répondent à des parties différentes de celle-ci. Notez contre quel observateur vous vous défendez avant d’en choisir un.

Adaptez le correctif à la panne réelle

Pour un VPN lent ordinaire, remplacer par un tunnel transporté par DNS ajoute un transport contraint par-dessus le problème. Cela ne répare ni la qualité radio, ni la congestion, ni la charge du serveur, et cela les rend généralement plus visibles.

Pour les défaillances de noms privés, examinez d’abord la politique de résolveur prévue : quel serveur doit répondre, quels noms sont concernés et si le client est autorisé à l’utiliser. Choisissez ensuite un transport autorisé qui correspond à l’exigence, et conservez la configuration du résolveur dans le journal des changements afin que l’incident suivant ne relance pas la même recherche.

La liste de vérification est courte : identifiez le dispositif, confirmez ce que transportent les messages, mesurez la capacité, puis examinez la confiance. Toute étape qui ne correspond pas au symptôme signifie que les deux autres dispositifs sont encore en jeu.