Die Entwickler des BIND-DNS-Servers kündigten die Hinzufügung von Serverunterstützung für die Technologien DNS über HTTPS (DoH, DNS über HTTPS) und DNS über TLS (DoT, DNS über TLS) sowie den XFR-über-TLS-Mechanismus für Sicherheit an Übertragen des Inhalts von DNS-Zonen zwischen Servern. DoH steht in Version 9.17 zum Testen zur Verfügung und DoT-Unterstützung gibt es seit Version 9.17.10. Nach der Stabilisierung wird die DoT- und DoH-Unterstützung auf den stabilen 9.17.7-Zweig zurückportiert.
Die Implementierung des in DoH verwendeten HTTP/2-Protokolls basiert auf der Verwendung der nghttp2-Bibliothek, die zu den Assembly-Abhängigkeiten gehört (in Zukunft soll die Bibliothek in die Anzahl der optionalen Abhängigkeiten überführt werden). Es werden sowohl verschlüsselte (TLS) als auch unverschlüsselte HTTP/2-Verbindungen unterstützt. Mit den entsprechenden Einstellungen kann ein einzelner benannter Prozess nun nicht nur herkömmliche DNS-Anfragen bedienen, sondern auch Anfragen, die über DoH (DNS-over-HTTPS) und DoT (DNS-over-TLS) gesendet werden. HTTPS-Unterstützung auf der Clientseite (dig) ist noch nicht implementiert. XFR-over-TLS-Unterstützung ist sowohl für eingehende als auch für ausgehende Anfragen verfügbar.
Die Anforderungsverarbeitung mithilfe von DoH und DoT wird durch Hinzufügen der Optionen http und tls zur Listen-On-Direktive aktiviert. Um unverschlüsseltes DNS-over-HTTP zu unterstützen, sollten Sie in den Einstellungen „tls none“ angeben. Schlüssel werden im Abschnitt „tls“ definiert. Die Standard-Netzwerkports 853 für DoT, 443 für DoH und 80 für DNS-over-HTTP können über die Parameter tls-port, https-port und http-port überschrieben werden. Zum Beispiel: tls local-tls { key-file „/path/to/priv_key.pem“; Zertifikatsdatei „/path/to/cert_chain.pem“; }; http local-http-server { endpoints { "/dns-query"; }; }; Optionen { https-port 443; Abhörport 443 tls local-tls http myserver {any;}; }
Zu den Funktionen der DoH-Implementierung in BIND gehört die Integration als allgemeiner Transport, der nicht nur zur Verarbeitung von Client-Anfragen an den Resolver, sondern auch beim Datenaustausch zwischen Servern, bei der Zonenübertragung durch einen autorisierenden DNS-Server usw. verwendet werden kann bei der Verarbeitung von Anfragen, die von anderen DNS-Transporten unterstützt werden.
Eine weitere Funktion ist die Möglichkeit, Verschlüsselungsvorgänge für TLS auf einen anderen Server zu verschieben, was unter Umständen erforderlich sein kann, wenn TLS-Zertifikate auf einem anderen System (z. B. in einer Infrastruktur mit Webservern) gespeichert und von anderem Personal verwaltet werden. Die Unterstützung für unverschlüsseltes DNS-over-HTTP dient der Vereinfachung des Debuggings und als Schicht für die Weiterleitung im internen Netzwerk, auf deren Grundlage die Verschlüsselung auf einem anderen Server organisiert werden kann. Auf einem Remote-Server kann nginx zum Generieren von TLS-Verkehr verwendet werden, ähnlich wie die HTTPS-Bindung für Websites organisiert ist.
Erinnern wir uns daran, dass DNS-over-HTTPS nützlich sein kann, um Informationslecks über die angeforderten Hostnamen über die DNS-Server von Anbietern zu verhindern, MITM-Angriffe und DNS-Traffic-Spoofing (z. B. beim Herstellen einer Verbindung zu öffentlichem WLAN) zu bekämpfen und entgegenzuwirken Blockierung auf DNS-Ebene (DNS-über-HTTPS kann ein VPN nicht ersetzen, indem es die auf DPI-Ebene implementierte Blockierung umgeht) oder zur Arbeitsorganisation, wenn es nicht möglich ist, direkt auf DNS-Server zuzugreifen (z. B. bei der Arbeit über einen Proxy). Wenn im Normalfall DNS-Anfragen direkt an die in der Systemkonfiguration definierten DNS-Server gesendet werden, wird bei DNS-over-HTTPS die Anfrage zur Ermittlung der Host-IP-Adresse im HTTPS-Verkehr gekapselt und an den HTTP-Server gesendet, wo Der Resolver verarbeitet Anfragen über die Web-API.
„DNS über TLS“ unterscheidet sich von „DNS über HTTPS“ durch die Verwendung des Standard-DNS-Protokolls (normalerweise wird Netzwerkport 853 verwendet), eingebettet in einen verschlüsselten Kommunikationskanal, der mithilfe des TLS-Protokolls mit Host-Gültigkeitsprüfung durch zertifizierte TLS/SSL-Zertifikate organisiert ist durch eine Zertifizierungsstelle. Der bestehende DNSSEC-Standard verwendet Verschlüsselung nur zur Authentifizierung von Client und Server, schützt den Datenverkehr jedoch nicht vor dem Abfangen und garantiert nicht die Vertraulichkeit von Anfragen.
Source: opennet.ru