Waarom een DNS-wijziging geen SOCKS-proxy instelt
Legt uit waarom het verwijzen van de hostnaam van een website naar een SOCKS-server een niet-geconfigureerde browser de proxy niet laat gebruiken.
Een DNS-antwoord wijzigen verandert alleen het adres waarmee de browser verbinding maakt. Het verandert niet het protocol dat de browser spreekt zodra hij daar aankomt.
Bij een gewone HTTP-adres stuurt de browser HTTP. Bij een HTTPS-adres start hij TLS voor die website. Een SOCKS5-server verwacht echter eerst zijn eigen onderhandeling: methodekeuze, eventuele authenticatie en een verzoek dat de bestemming noemt. Een niet-geconfigureerde browser stuurt daar niets van.
Dat verklaart waarom een bereikbare Dante-listener direct na een DNS-wijziging een verbinding kan sluiten. De dienst kan gezond zijn; de inkomende bytes horen bij het verkeerde protocol. De listener naar poort 80 of 443 verplaatsen maakt die bytes niet tot SOCKS.
Configureer de SOCKS-interface van een browser, bijvoorbeeld de SOCKS-instellingen van Firefox, of een applicatiespecifieke proxyinstelling, zodat hij de handshake uitvoert en de proxy vraagt verder te verbinden. Een PAC-bestand kan een ondersteunde proxyroute kiezen voor applicaties die het gebruiken. Het blijft een aparte proxyconfiguratie, geen eigenschap van een A- of AAAA-record.
HTTPS voegt nog een hindernis toe aan het idee van alleen DNS. De browser blijft de identiteit van de website in de URL verwachten. Een certificaat voor de proxyhost kan aan die verwachting niet voldoen, alleen omdat DNS de verbinding daarheen stuurde.
Transparante netwerkinterceptie is een ander ontwerp met routering en compatibele interceptiesoftware. Die krijg je niet door het adres van een SOCKS-server uit DNS terug te geven.