Perché un cambio DNS non configura un proxy SOCKS
Spiega perché indirizzare il nome host di un sito verso un server SOCKS non fa usare il proxy a un browser non configurato.
Cambiare una risposta DNS cambia solo l'indirizzo a cui il browser si connette. Non cambia il protocollo che il browser parla una volta arrivato lì.
Con un normale URL HTTP il browser invia HTTP. Con un URL HTTPS avvia TLS per quel sito. Un server SOCKS5 però attende prima la propria negoziazione: scelta del metodo, eventuale autenticazione e una richiesta che nomina la destinazione. Un browser non configurato non ne invia nulla.
Questo spiega perché un listener Dante raggiungibile può chiudere subito una connessione dopo un cambio DNS. Il servizio può essere sano; i byte in arrivo appartengono al protocollo sbagliato. Spostare il listener sulla porta 80 o 443 non trasforma quei byte in SOCKS.
Configura l'interfaccia SOCKS del browser, ad esempio le impostazioni SOCKS di Firefox, o un'impostazione proxy specifica dell'applicazione, così che esegua lo handshake e chieda al proxy di connettersi oltre. Un file PAC può scegliere un percorso proxy supportato per le applicazioni che lo usano. Resta comunque una configurazione proxy separata, non una proprietà di un record A o AAAA.
HTTPS aggiunge un altro ostacolo all'idea del solo DNS. Il browser continua ad attendersi l'identità del sito presente nell'URL. Un certificato per l'host del proxy non può soddisfare questa attesa solo perché il DNS ha inviato lì la connessione.
L'intercettazione di rete trasparente è un progetto diverso che comporta instradamento e software di intercettazione compatibile. Non si ottiene restituendo l'indirizzo di un server SOCKS dal DNS.