Firefox-Entwickler Wir haben die Tests zur Unterstützung von DNS über HTTPS (DoH, DNS over HTTPS) abgeschlossen und planen, diese Technologie Ende September standardmäßig für Nutzer in den USA zu aktivieren. Die Aktivierung erfolgt schrittweise, zunächst für einige Prozent der Nutzer. Bei Auftreten von Problemen wird die Abdeckung schrittweise auf 100% erhöht. Nach der Aktivierung in den USA wird geprüft, ob DoH auch in anderen Ländern implementiert werden kann.
Die im Laufe des Jahres durchgeführten Tests haben die Zuverlässigkeit und gute Leistung des Dienstes gezeigt und einige Situationen identifiziert, in denen DoH zu Problemen führen kann. Lösungen wurden entwickelt, um diesen Herausforderungen zu begegnen (zum Beispiel in Bezug auf die Optimierung des Datenverkehrs in Content Delivery Netzwerken, elterliche Kontrolle und Unternehmens-DNS-Zonen).
Die Bedeutung der Verschlüsselung des DNS-Verkehrs wird als grundlegend für den Schutz der Benutzer angesehen. Daher wurde beschlossen, DoH standardmäßig zu aktivieren, allerdings zunächst nur für Nutzer in den USA. Nach der Aktivierung von DoH erhält der Benutzer eine Warnmeldung, die es ihm ermöglicht, auf Wunsch auf die Verwendung von zentralisierten DoH-DNS-Servern zu verzichten und zum traditionellen Ansatz zurückzukehren, der unverschlüsselte Anfragen an den DNS-Server des Anbieters sendet. Im Gegensatz zur verteilten Infrastruktur der DNS-Resolver bindet DoH an einen bestimmten DoH-Dienst, der als einzelner Ausfallpunkt betrachtet werden kann.
Die Aktivierung von DoH kann zu Störungen bei der Funktion von Elternkontrollsystemen und Unternehmensnetzwerken führen, die eine nur im internen Netzwerk verfügbare DNS-Namensstruktur zur Umwandlung von Intranet-Adressen und unternehmensinternen Hosts verwenden. Um Probleme mit solchen Systemen zu lösen, wurde ein Prüfmechanismus implementiert, der DoH automatisch deaktiviert. Die Überprüfungen erfolgen bei jedem Start des Browsers oder beim Erkennen einer Subnetzänderung.
Die automatische Rückkehr zur Verwendung des integrierten Resolver der Betriebssysteme ist ebenfalls vorgesehen, wenn es zu Störungen beim Auflösen über DoH kommt (zum Beispiel bei einer Unterbrechung der Netzverbindung mit dem DoH-Anbieter oder bei Ausfällen seiner Infrastruktur). Der Sinn solcher Überprüfungen ist fragwürdig, da es Angreifern, die den Betrieb des Resolvers kontrollieren oder in den Datenverkehr eingreifen können, nicht schwerfällt, ein ähnliches Verhalten zu simulieren, um die Verschlüsselung des DNS-Datenverkehrs zu deaktivieren. Das Problem wurde durch die Hinzufügung der Option „DoH immer“ in die Einstellungen gelöst (standardmäßig nicht aktiviert). Bei Aktivierung dieser Option wird die automatische Deaktivierung nicht angewendet, was einen vernünftigen Kompromiss darstellt.
Um Unternehmens-Resolver zu identifizieren, werden Prüfungen auf ungewöhnliche Top-Level-Domains (TLD) durchgeführt und die Rückgabe von Intranet-Adressen durch den Systemresolver erfolgt. Um zu bestimmen, ob die Kindersicherung aktiviert ist, erfolgt ein Versuch, den Namen exampleadultsite.com aufzulösen, und wenn das Ergebnis nicht mit der tatsächlichen IP übereinstimmt, wird angenommen, dass die Blockierung von Inhalts für Erwachsene auf DNS-Ebene aktiv ist. Zudem werden auch die IP-Adressen von Google und YouTube auf mögliche Umleitungen zu restrict.youtube.com, forcesafesearch.google.com und restrictmoderate.youtube.com geprüft. Zusätzlich Mozilla einen einheitlichen Prüf-Host implementieren , der von Internetanbietern und Kindersicherungsdiensten als Tag zur Deaktivierung von DoH genutzt werden kann (falls der Host nicht bestimmt werden kann, deaktiviert Firefox DoH).
Die Nutzung eines einheitlichen DoH-Dienstes kann auch potenziell zu Problemen bei der Traffic-Optimierung in Content Delivery Networks führen, die Traffic mithilfe von DNS ausbalancieren (der DNS-Server des CDN-Netzes erstellt eine Antwort unter Berücksichtigung der Adresse des Resolvers und gibt den nächstgelegenen Host für den Content aus). Das Senden einer DNS-Anfrage vom nächstgelegenen Resolver des Nutzers in solchen CDNs führt zur Rückgabe der Adresse des nächstgelegenen Hosts, während bei einer DNS-Anfrage von einem zentralisierten Resolver die Adresse des Hosts ausgegeben wird, der dem DNS-over-HTTPS-Server am nächsten ist. Praktische Tests haben gezeigt, dass die Anwendung von DNS-over-HTTP bei der Verwendung von CDNs praktisch keine Verzögerungen beim Start der Inhaltsübertragung mit sich brachte (bei schnellen Verbindungen betrugen die Verzögerungen nicht mehr als 10 Millisekunden, und bei langsamen Verbindungen konnte sogar eine Beschleunigung festgestellt werden). Um dem CDN-Resolver Informationen über den Standort des Clients zu übermitteln, wurde auch die Anwendung der Erweiterung EDNS Client Subnet erwogen.
Erinnern Sie sich daran, dass DoH nützlich sein kann, um Informationslecks über angeforderte Hostnamen durch die DNS-Server der Provider zu verhindern, gegen MITM-Angriffe und DNS-Traffic-Manipulationen zu kämpfen, DNS-Sperren zu umgehen oder um den Betrieb sicherzustellen, wenn ein direkter Zugriff auf die DNS-Server nicht möglich ist (z. B. bei der Nutzung eines Proxys). Während in der Regel DNS-Anfragen direkt an die in der Systemkonfiguration angegebenen DNS-Server gesendet werden, wird bei DoH die Anfrage zur Ermittlung der IP-Adresse des Hosts im HTTPS-Traffic eingekapselt und an einen HTTP-Server gesendet, wo der Resolver die Anfragen über eine Web-API verarbeitet. Der bestehende Standard DNSSEC verwendet Verschlüsselung nur zur Authentifizierung des Clients und des Servers, schützt jedoch den Traffic nicht vor Abhörung und garantiert keine Vertraulichkeit der Anfragen.
Um DoH in about:config zu aktivieren, muss der Wert der Variable network.trr.mode geändert werden, die seit Firefox 60 unterstützt wird. Der Wert 0 schaltet DoH vollständig aus; 1 verwendet entweder DNS oder DoH, je nachdem, was schneller ist; 2 verwendet standardmäßig DoH und DNS als Backup; 3 verwendet nur DoH; 4 ist der Spiegelmodus, in dem DoH und DNS parallel verwendet werden. Standardmäßig wird der CloudFlare-DNS-Server verwendet, kann jedoch über den Parameter network.trr.uri geändert werden, zum Beispiel „https://dns.google.com/experimental“ oder „https://9.9.9.9/dns-query“.
Quelle: opennet.ru
