SOCKS5 ou SOCKS5h : où se fait la résolution DNS ?

Comparez la résolution DNS locale et côté proxy dans curl, identifiez les échecs de résolution et comprenez la portée réelle de socks5h.

Avec curl, choisissez socks5h:// lorsque le proxy doit résoudre le nom de destination. Choisissez socks5:// lorsque curl doit le résoudre localement et transmettre une adresse au proxy. Les deux utilisent SOCKS5 ; le h final est une convention d’URL propre au client.

Comparez les deux modes en remplaçant le point d’écoute local par votre point de connexion SOCKS5 :

curl --noproxy '' --proxy socks5://127.0.0.1:1080 --connect-timeout 5 --max-time 15 --verbose https://example.com/
curl --noproxy '' --proxy socks5h://127.0.0.1:1080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

Seul le mode de résolution change. --noproxy '' supprime les règles de contournement pour ces appels, et les délais limitent la durée de la comparaison. Les options dédiées équivalentes sont --socks5 et --socks5-hostname. Utilisez un nom d’hôte comme cible : une adresse IP littérale ne nécessite aucune résolution de destination et ne permet pas de montrer cette différence.

Un nom peut n’exister que d’un côté

Supposons que le proxy fonctionne dans un réseau de développement dont le DNS connaît le nom d’un service interne. Votre ordinateur portable peut ne pas résoudre ce nom en mode socks5, alors que socks5h laisse le proxy le résoudre. Inversez la situation, avec un nom défini uniquement dans le fichier hosts de votre ordinateur : c’est alors la résolution distante qui peut échouer.

Le DNS public peut lui aussi renvoyer des adresses différentes selon le réseau. Des résultats différents invitent à comparer les adresses sélectionnées et leur accessibilité, plutôt qu’à remplacer immédiatement le proxy.

  • Impossible de résoudre le nom d’hôte du proxy : aucun des deux modes ne peut démarrer. Votre client résout toujours proxy.example dans socks5h://proxy.example:1080.
  • Échec de la résolution locale de la destination : examinez le résolveur du client ou comparez avec le mode de résolution du nom par le proxy.
  • Le serveur SOCKS refuse la destination : examinez sa réponse et sa politique. Une résolution locale réussie ne garantit pas l’accessibilité depuis le réseau distant.
  • Le tunnel fonctionne, mais la vérification du certificat échoue : recherchez le problème dans le TLS de destination ; changer de mode DNS ne résout pas tous les problèmes de confiance.

Un nom de test que vous contrôlez et les journaux du serveur permettent de confirmer quel type d’adresse est parvenu à un proxy que vous administrez. Une page affichant l’IP de sortie ne le permet pas : elle décrit la connexion sortante, pas l’endroit où la résolution DNS a eu lieu.

Le gain de confidentialité a une portée précise

La résolution côté proxy évite la résolution locale de la destination pour cette requête. Elle ne chiffre pas SOCKS, ne prouve pas que le proxy utilise un DNS chiffré et n’achemine pas le trafic des autres applications ni celui du préchargement du navigateur. Requests, avec la prise en charge de SOCKS, applique la même distinction entre résolution locale et côté proxy ; d’autres clients peuvent proposer un réglage plutôt que la notation d’URL de curl. Choisissez un protocole pris en charge par votre application avant de copier un point de connexion depuis la liste de proxys SOCKS5.

Articles similaires