Por qué un cambio de DNS no configura un proxy SOCKS
Explica por qué dirigir el nombre de host de un sitio web a un servidor SOCKS no hace que un navegador sin configurar use el proxy.
Cambiar una respuesta DNS solo cambia la dirección a la que se conecta el navegador. No cambia el protocolo que habla el navegador cuando llega allí.
Al visitar una URL HTTP normal, el navegador envía HTTP. Al visitar una URL HTTPS, inicia TLS para ese sitio. Un servidor SOCKS5 espera primero su propia negociación: selección de método, cualquier autenticación y una petición que nombre el destino. Un navegador sin configurar no envía nada de eso.
Esto explica por qué un listener Dante accesible puede cerrar una conexión de inmediato tras un cambio de DNS. El servicio puede estar sano; los bytes entrantes pertenecen al protocolo equivocado. Mover el listener al puerto 80 o 443 no convierte esos bytes en SOCKS.
Configure la interfaz SOCKS del navegador, como los ajustes SOCKS de Firefox, o un ajuste de proxy específico de la aplicación, para que realice el handshake y pida al proxy que conecte más allá. Un archivo PAC puede elegir una ruta de proxy admitida para las aplicaciones que lo usan. Sigue siendo una configuración de proxy aparte, no una propiedad de un registro A o AAAA.
HTTPS añade otro obstáculo a la idea de solo DNS. El navegador sigue esperando la identidad del sitio en la URL. Un certificado para el host del proxy no puede satisfacer esa expectativa solo porque DNS envió allí la conexión.
La interceptación de red transparente es un diseño distinto que implica enrutamiento y software de interceptación compatible. No se obtiene devolviendo la dirección de un servidor SOCKS desde DNS.