
Ich habe einen DNS-Server in unserem privaten Netzwerk unter IP 10.10.0.10 laufen. Die DNS-Server lösen URLs auch innerhalb unseres Netzwerks in private IPs auf. SSL für alle URLs wird durch ein Wildcard-Zertifikat für eine .BIZ-Domäne abgewickelt. Aber seit kurzem aktivieren Chrome und Firefox DNS-over-HTTPS im Rahmen der letzten Updates. Da unser DNS-Server nicht DOH-kompatibel ist, können Benutzer nicht zu unseren URLs navigieren, es sei denn, sie deaktivieren die DOH-Funktion in ihrem Browser.
Im Idealfall möchte ich, dass unsere Benutzer DOH in ihren Browsern aktiviert lassen und sich weiterhin auf den lokalen DNS-Server verlassen, um URLs in unsere privaten IPs aufzulösen. Um dies zu erreichen, habe ich mir angesehendoh-proxy. Ich habe eine Centos-7-VM auf IP 10.10.0.20 gestartet, doh-proxy installiert und Port 443 geöffnet. Dann habe ich Folgendes ausgeführt:
/usr/local/bin/doh-proxy --upstream-resolver=10.10.0.10 --certfile=/etc/pki/public/mycompany.bundle.biz.crt --keyfile=/etc/pki/private/mycompany.biz.pem
Mithilfe von netstat habe ich überprüft, dass Port 443 lauschte. Anschließend habe ich meine VPN-Konfiguration geändert, um die DNS-Einstellung von 10.10.0.10 auf 10.10.0.20 (den neuen Doh-Proxyserver) zu ändern. Allerdings konnte ich mit aktiviertem DOH im Browser immer noch nicht zu unseren URLs navigieren.
Missverstehe ich die Absicht hinter dem Doh-Proxy?
Antwort1
Ich glaube nicht, dass Sie die Absicht dahinter missverstehen doh-proxy
, es scheint sich um ein DoH-Frontend für einen regulären DNS-Resolver-Server zu handeln, das DoH-Clients eine Möglichkeit bietet, den besagten Resolver-Server abzufragen.
Es gibt mehrere andere solcher Proxy-Lösungen, falls sich diese spezielle Implementierung aus irgendeinem Grund als ungeeignet erweisen sollte.
Was Sie meiner Meinung nach jedoch möglicherweise missverstanden/übersehen haben, ist, dass der Client zum Konfigurieren von DoH die URL des DoH-Servers kennen muss (z. B. https://dns.quad9.net/dns-query
, https://dns.google/dns-query
, usw.). Eine bloße IP-Adresse bringt für die Einrichtung von DoH nichts.
Und um die Sache noch komplizierter zu machen, verfügt das DoH derzeit über keinen geeigneten Erkennungsmechanismus. (Das ist die eigentliche Ursache für viele Kontroversen rund um das DoH, insbesondere im Hinblick auf Mozillas Ansatz.)
Beispiele, wie „DoH standardmäßig aktiviert“ an dieser Stelle funktioniert:
- Firefox ist so eingestellt, dass er weiß, welcher DoH-Server verwendet werden soll (Mozilla wählt im Namen seiner Benutzer einen DoH-Dienst aus und berücksichtigt dabei nicht die Betriebssystemkonfiguration).
- Chrome führt selektiv Upgrades von einfachem DNS auf DoH durch, basierend auf einer Zuordnungstabelle mit bekannten IP-Adressen von DNS-Diensten als Schlüssel, z. B.
8.8.8.8 -> https://dns.google/dns-query
(Google pflegt eine Zuordnungstabelle für bekannte DNS-Dienste und das DoH-Upgrade erfolgt nur, wenn die Zuordnungstabelle die Abfrage desselben DNS-Dienstes ermöglicht, den die Betriebssystemkonfiguration für einfaches DNS angibt).
Alles in allem ist es recht einfach, einen eigenen DoH-Dienst zu betreiben, aber nicht unbedingt einfach, Kunden dazu zu bringen, ihn zu verwenden.
Sie müssen den Clients irgendwie mitteilen, dass sie https://dns.example.com/dns-query
(sofern wir davon ausgehen, dass dies die richtige URL für Ihren Proxy ist) als ihren DoH-Endpunkt verwenden sollen, was in seiner einfachsten Form wahrscheinlich eine manuelle Konfiguration auf den Clients bedeutet (und zwar pro Anwendung).
Sie können sicherlich Möglichkeiten finden, die Konfiguration einer Reihe bekannter Anwendungen zu automatisieren, aber derzeit gibt es keine etablierte Erkennungsmethode, die vergleichbar wäre mit der Art und Weise, wie beispielsweise DHCP die Adressen für einfaches DNS bereitstellen kann.