Wêrom't in DNS-wiziging gjin SOCKS-proxy opsette kin
Ferklaret wêrom't it rjochtsjen fan 'e hostnamme fan in webside nei in SOCKS-tsjinner in net-ynstelde browser net de proxy brûke lit.
In DNS-antwurd feroarje feroaret allinnich it adres dêr't de browser mei ferbynt. It feroaret net it protokol dat de browser praat as er dêr oankommen is.
By in gewoane HTTP-adres stjoert de browser HTTP. By in HTTPS-adres begjint er TLS foar dy webside. In SOCKS5-tsjinner ferwachtet earst syn eigen ûnderhanneling: kar fan metoade, eventuele autentikaasje en in fersyk dat de bestimming neamt. In net-ynstelde browser stjoert dêr neat fan.
Dat ferklearret wêrom't in berikbere Dante-harker daliks in ferbining slute kin nei in DNS-wiziging. De tsjinst kin sûn wêze; de ynkommende bytes hearre by it ferkearde protokol. De harker nei poarte 80 of 443 ferpleatse makket dy bytes net SOCKS.
Stel de SOCKS-ynterface fan in browser yn, bygelyks de SOCKS-ynstellingen fan Firefox, of in applikaasjespesifike proxy-ynstelling, sadat er de hânskud docht en de proxy freget om fierder te ferbinen. In PAC-bestân kin in stipe proxyrûte kieze foar applikaasjes dy't it brûke. It bliuwt in aparte proxy-konfiguraasje, net in eigenskip fan in A- of AAAA-record.
HTTPS foeget noch in obstakel ta oan it allinnich-DNS-idee. De browser bliuwt de identiteit fan 'e webside yn 'e adres ferwachtsje. In sertifikaat foar de proxy-host kin oan dy ferwachting net foldwaan, allinnich omdat DNS de ferbining dêrhinne stjoerd hat.
Transparante netwurkyntereksje is in oar ûntwerp mei routing en kompatibele yntereksjesoftware. It is net te krijen troch it adres fan in SOCKS-tsjinner út DNS werom te jaan.