Die Entwickler des DNS-Servers BIND haben die Hinzufügung von Serverunterstützung für die Technologien „DNS über HTTPS“ (DoH, DNS over HTTPS) und DNS über TLS (DoT, DNS over TLS) in den experimentellen Branch 9.17 sowie einen Mechanismus für XFR-over-TLS zur sicheren Übertragung von DNS-Zoneninhalten zwischen Servern angekündigt. DoH ist in der Version 9.17.10 zum Testen verfügbar, während die Unterstützung von DoT ab der Version 9.17.7 vorhanden ist. Nach der Stabilisierung wird die Unterstützung für DoT und DoH in den stabilen Branch 9.16 zurückportiert.
Die Implementierung des Protokolls HTTP/2, das in DoH verwendet wird, basiert auf der Verwendung der Bibliothek nghttp2, die zu den Build-Abhängigkeiten gehört (zukünftig soll die Bibliothek in die Gruppe der optionalen Abhängigkeiten verschoben werden). Sowohl verschlüsselte (TLS) als auch unverschlüsselte Verbindungen über HTTP/2 werden unterstützt. Bei entsprechender Konfiguration kann ein Prozess von named nun nicht nur traditionelle DNS-Anfragen bedienen, sondern auch Anfragen, die über DoH (DNS-over-HTTPS) und DoT (DNS-over-TLS) gesendet werden. Die Unterstützung von HTTPS auf der Client-Seite (dig) ist derzeit noch nicht implementiert. Die Unterstützung von XFR-over-TLS steht sowohl für eingehende als auch für ausgehende Anfragen zur Verfügung.
Die Verarbeitung von Anfragen mit DoH und DoT wird durch das Hinzufügen von HTTP- und TLS-Optionen in der Direktive "listen-on" aktiviert. Um unverschlüsseltes DNS-over-HTTP zu unterstützen, sollte in den Einstellungen "tls none" angegeben werden. Die Schlüssel werden im Abschnitt "tls" definiert. Die Standardnetzwerkports sind 853 für DoT, 443 für DoH und 80 für DNS-over-HTTP, die durch die Parameter tls-port, https-port und http-port überschrieben werden können. Zum Beispiel: tls local-tls { key-file "/path/to/priv_key.pem"; cert-file "/path/to/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; }
Bei der Implementierung von DoH in BIND wird die Integration als gemeinsamer Transport hervorgehoben, der nicht nur zur Bearbeitung von Clientanfragen an den Resolver verwendet werden kann, sondern auch beim Austausch von Daten zwischen Servern, beim Übertragen von Zonen durch den autoritativen DNS-Server und bei der Bearbeitung von Anfragen, die von anderen DNS-Transporten unterstützt werden.
Eine weitere Funktion ist die Möglichkeit, die Verschlüsselungsoperationen für TLS auf einen anderen Server auszulagern. Dies kann erforderlich sein, wenn TLS-Zertifikate auf einem anderen System (zum Beispiel in einer Infrastruktur mit Webservern) gespeichert und von anderem Personal verwaltet werden. Die Unterstützung für unverschlüsseltes DNS-over-HTTP wurde implementiert, um das Debugging zu erleichtern und als Grundlage für die Durchleitung im internen Netzwerk, auf dessen Basis die Verschlüsselung auf einem anderen Server organisiert werden kann. Auf dem Auslagerungsserver kann nginx zur Generierung des TLS-Traffics verwendet werden, ähnlich wie bei der HTTPS-Bindung für Websites.
Wir erinnern daran, dass DNS-over-HTTPS nützlich sein kann, um Lecks von Informationen über angeforderte Hostnamen über die DNS-Server der Anbieter zu verhindern, gegen MITM-Angriffe und DNS-Traffic-Manipulationen (z. B. bei der Verbindung zu öffentlichen Wi-Fi) zu kämpfen und DNS-Sperren zu umgehen (DNS-over-HTTPS kann nicht ersetzen VPN im Bereich der Umgehung von Sperren, die auf DPI-Ebene implementiert sind) oder um den Betrieb zu organisieren, falls kein direkter Zugriff auf die DNS-Server möglich ist (z. B. bei der Nutzung eines Proxys). Während in der Regel die DNS-Anfragen direkt an die im Systemkonfiguration angegebenen DNS-Server gesendet werden, erfolgt im Fall von DNS-over-HTTPS die Anfrage zur Bestimmung IP-Adressen Der Host wird in HTTPS-Traffic eingekapselt und an den HTTP-Server gesendet, wo der Resolver die Anfragen über die Web-API verarbeitet.
„DNS über TLS“ unterscheidet sich von „DNS über HTTPS“ durch die Verwendung des Standardprotokolls DNS (normalerweise über den Netzwerkport 853), das in einen verschlüsselten Kommunikationskanal eingebettet ist, der durch das TLS-Protokoll organisiert ist, mit Host-Validierung über TLS/SSL-Zertifikate, die von einer Zertifizierungsstelle beglaubigt wurden. Der bestehende DNSSEC-Standard nutzt Verschlüsselung nur zur Authentifizierung von Client und Server, schützt jedoch den Datenverkehr nicht vor Abfangen und garantiert nicht die Vertraulichkeit der Anfragen.
Quelle: opennet.ru
