Varför en DNS-ändring inte kan ställa in en SOCKS-proxy
Förklarar varför det att peka en webbplats värdnamn mot en SOCKS-server inte får en okonfigurerad webbläsare att använda proxyn.
Att ändra ett DNS-svar ändrar bara den adress som webbläsaren ansluter till. Det ändrar inte det protokoll som webbläsaren talar när den har kommit dit.
Vid en vanlig HTTP-adress skickar webbläsaren HTTP. Vid en HTTPS-adress startar den TLS för den webbplatsen. En SOCKS5-server väntar dock först på sin egen förhandling: metodval, eventuell autentisering och en begäran som namnger målet. En okonfigurerad webbläsare skickar inget av detta.
Det förklarar varför en nåbar Dante-lyssnare omedelbart kan stänga en anslutning efter en DNS-ändring. Tjänsten kan vara frisk; byten som kommer in tillhör fel protokoll. Att flytta lyssnaren till port 80 eller 443 gör inte dessa byten till SOCKS.
Konfigurera webbläsarens SOCKS-gränssnitt, till exempel Firefox SOCKS-inställningar, eller en programspecifik proxyinställning, så att den utför handskakningen och ber proxyn ansluta vidare. En PAC-fil kan välja en proxyrutt som stöds för program som använder den. Det är fortfarande en separat proxykonfiguration, inte en egenskap hos en A- eller AAAA-post.
HTTPS lägger till ytterligare ett hinder för idén med bara DNS. Webbläsaren fortsätter att förvänta sig webbplatsens identitet i adressen. Ett certifikat för proxyvärden kan inte uppfylla den förväntan bara för att DNS skickade anslutningen dit.
Transparent nätverksavlyssning är en annan konstruktion som innefattar routing och kompatibel avlyssningsprogramvara. Det går inte att få genom att returnera en SOCKS-servers adress från DNS.