Зошто промена на DNS не може да постави SOCKS прокси
Објаснува зошто насочувањето на името на домаќинот на веб-страницата кон SOCKS сервер не прави неконфигуриран прелистувач да го користи проксито.
Менувањето на DNS одговорот ја менува само адресата на која се поврзува прелистувачот. Не го менува протоколот на кој прелистувачот зборува откако ќе стигне таму.
При обична HTTP адреса прелистувачот праќа HTTP. При HTTPS адреса започнува TLS за таа страница. Но SOCKS5 серверот најпрво го чека своето преговарање: избор на метод, евентуална автентикација и барање што ја именува дестинацијата. Неконфигуриран прелистувач не праќа ништо од тоа.
Тоа објаснува зошто достапен Dante слушател може веднаш да ја затвори врската по промена на DNS. Услугата може да е здрава; дојдовните бајти ѝ припаѓаат на погрешниот протокол. Преместувањето на слушателот на портата 80 или 443 не ги претвора тие бајти во SOCKS.
Конфигурирајте го SOCKS интерфејсот на прелистувачот, на пример SOCKS поставките на Firefox, или поставка за прокси специфична за апликацијата, за да го изврши ракувањето и да побара од проксито да се поврзе понатаму. PAC датотека може да избере поддржана прокси рута за апликациите што ја користат. Тоа е сè уште одделна прокси конфигурација, а не својство на запис A или AAAA.
HTTPS додава уште една пречка на идејата само со DNS. Прелистувачот продолжува да го очекува идентитетот на страницата од адресата. Сертификат за домаќинот на проксито не може да го задоволи тоа очекување само затоа што DNS ја испратил врската таму.
Транспарентното мрежно пресретнување е поинаков дизајн што вклучува рутирање и компатибилен софтвер за пресретнување. Тоа не може да се добие со враќање на адресата на SOCKS сервер од DNS.