Pourquoi un changement DNS ne configure pas un proxy SOCKS
Explique pourquoi diriger le nom d'hôte d'un site vers un serveur SOCKS ne fait pas utiliser le proxy à un navigateur non configuré.
Changer une réponse DNS ne change que l'adresse à laquelle le navigateur se connecte. Cela ne change pas le protocole que le navigateur parle une fois arrivé.
Sur une URL HTTP ordinaire, le navigateur envoie du HTTP. Sur une URL HTTPS, il démarre TLS pour ce site. Un serveur SOCKS5 attend d'abord sa propre négociation : choix de méthode, éventuelle authentification et une requête nommant la destination. Un navigateur non configuré n'en envoie rien.
Cela explique pourquoi un écouteur Dante joignable peut fermer immédiatement une connexion après un changement DNS. Le service peut être sain ; les octets entrants relèvent du mauvais protocole. Déplacer l'écouteur sur le port 80 ou 443 ne transforme pas ces octets en SOCKS.
Configurez l'interface SOCKS du navigateur, par exemple les réglages SOCKS de Firefox, ou un réglage de proxy propre à l'application, pour qu'il effectue la poignée de main et demande au proxy de se connecter plus loin. Un fichier PAC peut choisir une route de proxy prise en charge pour les applications qui l'utilisent. Cela reste une configuration de proxy distincte, pas une propriété d'un enregistrement A ou AAAA.
HTTPS ajoute un autre obstacle à l'idée du DNS seul. Le navigateur continue d'attendre l'identité du site présente dans l'URL. Un certificat pour l'hôte du proxy ne peut pas satisfaire cette attente simplement parce que le DNS a envoyé la connexion là.
L'interception réseau transparente est une conception différente, impliquant du routage et un logiciel d'interception compatible. On ne l'obtient pas en renvoyant l'adresse d'un serveur SOCKS depuis le DNS.