De ce o modificare DNS nu configurează un proxy SOCKS
Explică de ce direcționarea numelui de gazdă al unui site către un server SOCKS nu face un browser neconfigurat să folosească proxy-ul.
Modificarea unui răspuns DNS schimbă doar adresa la care se conectează browserul. Nu schimbă protocolul pe care browserul îl vorbește după ce ajunge acolo.
La o adresă HTTP obișnuită browserul trimite HTTP. La o adresă HTTPS pornește TLS pentru acel site. Un server SOCKS5 însă așteaptă mai întâi propria negociere: alegerea metodei, eventuala autentificare și o cerere care numește destinația. Un browser neconfigurat nu trimite nimic din toate acestea.
Asta explică de ce un ascultător Dante accesibil poate închide imediat o conexiune după o modificare DNS. Serviciul poate fi sănătos; octeții care sosesc aparțin protocolului greșit. Mutarea ascultătorului pe portul 80 sau 443 nu transformă acei octeți în SOCKS.
Configurați interfața SOCKS a browserului, cum ar fi setările SOCKS din Firefox, sau o setare de proxy specifică aplicației, astfel încât să facă strângerea de mână și să ceară proxy-ului să conecteze mai departe. Un fișier PAC poate alege o rută de proxy acceptată pentru aplicațiile care îl folosesc. Rămâne o configurație de proxy separată, nu o proprietate a unei înregistrări A sau AAAA.
HTTPS adaugă încă un obstacol ideii de doar DNS. Browserul continuă să aștepte identitatea site-ului din adresă. Un certificat pentru gazda proxy-ului nu poate satisface această așteptare doar pentru că DNS a trimis conexiunea acolo.
Interceptarea transparentă a rețelei este un alt proiect care implică rutare și software de interceptare compatibil. Nu se obține returnând adresa unui server SOCKS din DNS.