Waarom 'n DNS-wysiging nie 'n SOCKS-volmag kan opstel nie
Verduidelik waarom dit nie 'n blaaier wat nie opgestel is nie, laat proxy gebruik nie wanneer 'n webwerf se gasheernaam na 'n SOCKS-bediener wys.
'n DNS-antwoord verander net die adres waarna die blaaier verbind. Dit verander nie die protokol wat die blaaier praat sodra hy daar aankom nie.
Besoek 'n gewone HTTP-URL en die blaaier stuur HTTP. Besoek 'n HTTPS-URL en hy begin TLS vir daardie webwerf. 'n SOCKS5-bediener verwag eers sy eie onderhandeling: keuse van metode, enige verifikasie en 'n versoek wat die bestemming noem. 'n Blaaier wat nie opgestel is nie, stuur niks daarvan nie.
Dit verduidelik hoekom 'n bereikbare Dante-luisteraar 'n verbinding dadelik kan sluit ná 'n DNS-wysiging. Die diens kan gesond wees; die inkomende grepe hoort by die verkeerde protokol. Om die luisteraar na poort 80 of 443 te skuif, maak nie daardie grepe SOCKS nie.
Stel 'n blaaier se SOCKS-koppelvlak op, soos Firefox se SOCKS-instellings, of 'n toepassing-spesifieke volmaginstelling, sodat dit die handdruk doen en die volmag vra om verder te verbind. 'n PAC-lêer kan 'n ondersteunde volmagroete kies vir toepassings wat dit gebruik. Dit bly 'n aparte volmagopstelling, nie 'n eienskap van 'n A- of AAAA-rekord nie.
HTTPS voeg nog 'n hindernis by die DNS-only idee. Die blaaier bly verwag die identiteit van die webwerf in die URL. 'n Sertifikaat vir die volmaggasheer kan nie daardie verwagting bevredig bloot omdat DNS die verbinding daarheen gestuur het nie.
Deursigtige netwerkonderskepping is 'n ander ontwerp met roetering en versoenbare onderskeppingsagteware. Jy kan dit nie kry deur 'n SOCKS-bediener se adres uit DNS te gee nie.