Bakit hindi makakapag-set up ng SOCKS proxy ang pagbabago ng DNS

Ang pagbabago ng sagot sa DNS ay nagbabago lamang ng address na kinokonektahan ng browser. Hindi nito binabago ang protocol na sinasalita ng browser kapag nakarating na doon.

Kapag bumisita sa ordinaryong HTTP URL, nagpapadala ng HTTP ang browser. Kapag bumisita sa HTTPS URL, nagsisimula ito ng TLS para sa site na iyon. Ang SOCKS5 server naman ay naghihintay muna ng sarili nitong negosasyon: pagpili ng paraan, anumang pagpapatunay, at kahilingang nagpapangalan sa destinasyon. Walang ipinapadala ang browser na hindi naka-configure.

Ito ang dahilan kung bakit ang maabot na Dante listener ay maaaring agad na magsara ng koneksyon pagkatapos ng pagbabago ng DNS. Maaaring malusog ang serbisyo; ang mga byte na dumarating ay para sa maling protocol. Ang ilipat ang listener sa port 80 o 443 ay hindi ginagawang SOCKS ang mga byte na iyon.

I-configure ang SOCKS interface ng browser, tulad ng mga setting ng SOCKS ng Firefox, o setting ng proxy na partikular sa application, upang gawin nito ang handshake at hilingin sa proxy na kumonekta pa. Maaaring pumili ang PAC file ng sinusuportahang ruta ng proxy para sa mga application na gumagamit nito. Hiwalay pa rin itong configuration ng proxy, hindi katangian ng A o AAAA record.

Nagdaragdag ang HTTPS ng isa pang hadlang sa ideyang DNS lamang. Patuloy na inaasahan ng browser ang pagkakakilanlan ng site na nasa URL. Hindi matutugunan ng sertipiko para sa host ng proxy ang inaasahang iyon dahil lang ipinadala ng DNS ang koneksyon doon.

Ang transparent na pagharang sa network ay ibang disenyo na may routing at compatible na software sa pagharang. Hindi ito makukuha sa pamamagitan ng pagbabalik ng address ng SOCKS server mula sa DNS.