Зашто 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-а.