Warum eine DNS-Änderung keinen SOCKS-Proxy einrichtet
Erklärt, warum ein unkonfigurierter Browser den Proxy nicht nutzt, wenn ein Hostname auf einen SOCKS-Server zeigt.
Eine DNS-Antwort zu ändern ändert nur die Adresse, zu der der Browser eine Verbindung aufbaut. Es ändert nicht das Protokoll, das der Browser spricht, sobald er dort angekommen ist.
Bei einer gewöhnlichen HTTP-Adresse sendet der Browser HTTP. Bei einer HTTPS-Adresse startet er TLS für diese Website. Ein SOCKS5-Server erwartet zuerst seine eigene Aushandlung: Methodenauswahl, eventuelle Authentifizierung und eine Anfrage, die das Ziel benennt. Ein unkonfigurierter Browser sendet nichts davon.
Das erklärt, warum ein erreichbarer Dante-Listener nach einer DNS-Änderung sofort eine Verbindung schließen kann. Der Dienst kann gesund sein; die eingehenden Bytes gehören zum falschen Protokoll. Den Listener auf Port 80 oder 443 zu verschieben macht diese Bytes nicht zu SOCKS.
Konfigurieren Sie die SOCKS-Schnittstelle des Browsers, etwa die SOCKS-Einstellungen von Firefox, oder eine anwendungsspezifische Proxy-Einstellung, damit er den Handshake ausführt und den Proxy bittet, weiter zu verbinden. Eine PAC-Datei kann für Anwendungen, die sie nutzen, einen unterstützten Proxyweg auswählen. Es bleibt eine eigene Proxy-Konfiguration, keine Eigenschaft eines A- oder AAAA-Eintrags.
HTTPS fügt der Nur-DNS-Idee ein weiteres Hindernis hinzu. Der Browser erwartet weiterhin die Identität der Website aus der Adresse. Ein Zertifikat für den Proxy-Host kann diese Erwartung nicht erfüllen, nur weil DNS die Verbindung dorthin geschickt hat.
Transparente Netzwerk-Interception ist ein anderes Design mit Routing und kompatibler Interception-Software. Sie lässt sich nicht dadurch erreichen, dass DNS die Adresse eines SOCKS-Servers zurückgibt.