Hvorfor en DNS-ændring ikke kan opsætte en SOCKS-proxy
Forklarer hvorfor det ikke får en ukonfigureret browser til at bruge proxyen, når et websteds værtsnavn peger på en SOCKS-server.
Ændring af et DNS-svar ændrer kun den adresse, browseren opretter forbindelse til. Det ændrer ikke den protokol, browseren taler, når den er nået dertil.
Besøger man en almindelig HTTP-adresse, sender browseren HTTP. Besøger man en HTTPS-adresse, starter den TLS for det websted. En SOCKS5-server forventer først sin egen forhandling: valg af metode, eventuel godkendelse og en anmodning, der navngiver destinationen. En ukonfigureret browser sender intet af det.
Det forklarer, hvorfor en tilgængelig Dante-listener straks kan lukke en forbindelse efter en DNS-ændring. Tjenesten kan være sund; de indgående bytes tilhører den forkerte protokol. At flytte listeneren til port 80 eller 443 gør ikke de bytes til SOCKS.
Konfigurer browserens SOCKS-grænseflade, for eksempel Firefox' SOCKS-indstillinger, eller en programspecifik proxyindstilling, så den udfører håndtrykket og beder proxyen om at forbinde videre. En PAC-fil kan vælge en understøttet proxyrute for programmer, der bruger den. Det er stadig en separat proxykonfiguration, ikke en egenskab ved en A- eller AAAA-post.
HTTPS tilføjer endnu en hindring for kun-DNS-ideen. Browseren fortsætter med at forvente webstedets identitet i adressen. Et certifikat til proxyværten kan ikke opfylde den forventning, blot fordi DNS sendte forbindelsen dertil.
Transparent netværksaflytning er et andet design, der involverer routing og kompatibel aflytningssoftware. Det kan ikke opnås ved at returnere en SOCKS-servers adresse fra DNS.