Kvifor ei DNS-endring ikkje kan setja opp ein SOCKS-proxy
Forklarer kvifor det å peika vertsnamnet til eit nettstad mot ein SOCKS-tenar ikkje får ein ukonfigurert nettlesar til å bruka proxyen.
Å endra eit DNS-svar endrar berre adressa nettlesaren koplar til. Det endrar ikkje protokollen nettlesaren snakkar når han har kome dit.
Ved ei vanleg HTTP-adresse sender nettlesaren HTTP. Ved ei HTTPS-adresse startar han TLS for nettstaden. Ein SOCKS5-tenar ventar derimot fyrst si eiga forhandling: val av metode, eventuell autentisering og ei førespurnad som namngjev målet. Ein ukonfigurert nettlesar sender ingenting av dette.
Det forklarer kvifor ein tilgjengeleg Dante-lyttar straks kan lukka ei tilkopling etter ei DNS-endring. Tenesta kan vera frisk; byta som kjem inn høyrer til feil protokoll. Å flytta lyttaren til port 80 eller 443 gjer ikkje desse byta til SOCKS.
Konfigurer SOCKS-grensesnittet til nettlesaren, til dømes SOCKS-innstillingane i Firefox, eller ei programspesifikk proxyinnstilling, slik at han gjer handtrykket og ber proxyen kopla vidare. Ei PAC-fil kan velja ei støtta proxyrute for program som brukar ho. Det er framleis ein eigen proxykonfigurasjon, ikkje ein eigenskap ved ein A- eller AAAA-post.
HTTPS legg til ein hindring meir for berre-DNS-ideen. Nettlesaren held fram med å venta identiteten til nettstaden i adressa. Eit sertifikat for proxyverten kan ikkje oppfylla den forventninga berre fordi DNS sende tilkoplinga dit.
Gjennomsiktig nettverksavlytting er eit anna design som inneber rutting og kompatibel avlyttingsprogramvare. Det kan ikkje oppnåast ved å returnera adressa til ein SOCKS-tenar frå DNS.