Nach zwei Jahren Entwicklung hat das ISC-Konsortium die erste stabile Version des neuen bedeutenden Zweigs des DNS-Servers BIND 9.18 vorgestellt. Der Support f\u00fcr den Zweig 9.18 wird bis zum zweiten Quartal 2025 im Rahmen eines erweiterten Wartungszyklus bereitgestellt. Die Unterst\u00fctzung f\u00fcr den Zweig 9.11 endet im M\u00e4rz, und der Zweig 9.16 wird Mitte 2023 eingestellt. F\u00fcr die Weiterentwicklung der Funktionen der n\u00e4chsten stabilen Version von BIND wurde ein experimenteller Zweig BIND 9.19.0 gebildet. <\/p>\n
Die Ver\u00f6ffentlichung von BIND 9.18.0 ist bemerkenswert, weil sie die Unterst\u00fctzung der Technologien \u201eDNS \u00fcber HTTPS\u201c (DoH, DNS over HTTPS) und DNS \u00fcber TLS (DoT, DNS over TLS) sowie den Mechanismus XoT (XFR-over-TLS) f\u00fcr die sichere \u00dcbertragung von DNS-Zoneninhalten zwischen Servern realisiert. Dabei wird sowohl der Empfang als auch der Versand von Zonen \u00fcber XoT unterst\u00fctzt. Bei entsprechender Konfiguration kann ein named-Prozess nun nicht nur traditionelle DNS-Anfragen bedienen, sondern auch Anfragen, die mit DNS-over-HTTPS und DNS-over-TLS gesendet werden. Die Clientunterst\u00fctzung f\u00fcr DNS-over-TLS ist in das Tool dig eingebaut, welches verwendet werden kann, um Anfragen \u00fcber TLS mit dem Flag \u201e+tls\u201c zu senden. <\/p>\n
Die Implementierung des HTTP\/2-Protokolls, das in DoH verwendet wird, basiert auf der Verwendung der nghttp2-Bibliothek, die zu den optionalen Build-Abh\u00e4ngigkeiten geh\u00f6rt. Die Zertifikate f\u00fcr DoH und DoT k\u00f6nnen vom Benutzer bereitgestellt oder w\u00e4hrend des Starts automatisch generiert werden. <\/p>\n
Die Verarbeitung von Anfragen mit DoH und DoT wird durch das Hinzuf\u00fcgen der Optionen \u201ehttp\u201c und \u201etls\u201c in der Direktive listen-on aktiviert. Um unverschl\u00fcsseltes DNS-over-HTTP zu unterst\u00fctzen, sollte in den Einstellungen \u201etls none\u201c angegeben werden. Die Schl\u00fcssel werden im Abschnitt \u201etls\u201c definiert. Die standardm\u00e4\u00dfigen Netzwerkports 853 f\u00fcr DoT, 443 f\u00fcr DoH und 80 f\u00fcr DNS-over-HTTP k\u00f6nnen \u00fcber die Parameter tls-port, https-port und http-port \u00fcberschrieben werden. Zum Beispiel: <\/p>\n
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;}; } <\/p>\n
Ein besonderes Merkmal der Implementierung von DoH in BIND ist die M\u00f6glichkeit, die Verschl\u00fcsselungsoperationen f\u00fcr TLS auf einen anderen Server auszulagern. Dies kann erforderlich sein, wenn TLS-Zertifikate in einem anderen System gespeichert sind (zum Beispiel in einer Infrastruktur mit Webservern) und von anderem Personal verwaltet werden. Die Unterst\u00fctzung von unverschl\u00fcsseltem DNS-over-HTTP wurde zur Vereinfachung der Fehlersuche und als Stufe f\u00fcr die Weiterleitung an einen anderen Server im internen Netzwerk implementiert (um die Verschl\u00fcsselung auf einen separaten Server auszulagern). Als auslagernder Server kann nginx zur Generierung des TLS-Traffics verwendet werden, \u00e4hnlich wie die HTTPS-Bindung f\u00fcr Websites organisiert ist. <\/p>\n
Ein weiteres Merkmal ist die Integration von DoH als allgemeines Transportprotokoll, das nicht nur zur Verarbeitung von Anfragen von Clients an den Resolver verwendet werden kann, sondern auch beim Datenaustausch zwischen Servern, bei der \u00dcbertragung von Zonen durch den autoritativen DNS-Server und bei der Verarbeitung aller Anfragen, die von anderen DNS-Transporten unterst\u00fctzt werden. <\/p>\n
Zu den Nachteilen, die durch das Deaktivieren des Aufbaus mit DoH\/DoT oder das Auslagern der Verschl\u00fcsselung auf einen anderen Server kompensiert werden k\u00f6nnen, z\u00e4hlt die allgemeine Komplexit\u00e4t des Codes \u2014 es wird ein integrierter HTTP-Server und eine TLS-Bibliothek hinzugef\u00fcgt, die potenzielle Schwachstellen enthalten und zus\u00e4tzliche Angriffsvektoren darstellen k\u00f6nnen. Zudem erh\u00f6ht sich bei der Verwendung von DoH der Datenverkehr. <\/p>\n
Wir erinnern daran, dass DNS-over-HTTPS n\u00fctzlich sein kann, um Lecks von Informationen \u00fcber angeforderte Hostnamen \u00fcber die DNS-Server der Anbieter zu verhindern, gegen MITM-Angriffe und DNS-Traffic-Manipulationen (z. B. bei der Verbindung zu \u00f6ffentlichen Wi-Fi) zu k\u00e4mpfen und DNS-Sperren zu umgehen (DNS-over-HTTPS kann nicht ersetzen VPN<\/a> 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\u00f6glich ist (z. B. bei der Nutzung eines Proxys). W\u00e4hrend 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<\/a> Der Host wird in HTTPS-Traffic eingekapselt und an den HTTP-Server gesendet, wo der Resolver die Anfragen \u00fcber die Web-API verarbeitet. <\/p>\n «DNS over TLS» unterscheidet sich von «DNS over HTTPS» durch die Verwendung des Standardprotokolls DNS (normalerweise Port 853), das in einen verschl\u00fcsselten Kommunikationskanal eingewickelt ist, der durch das TLS-Protokoll mit Hostvalidierung \u00fcber TLS\/SSL-Zertifikate, die von einer Zertifizierungsstelle ausgestellt sind, bereitgestellt wird. Der bestehende Standard DNSSEC verwendet Verschl\u00fcsselung nur zur Authentifizierung von Client und Server, sch\u00fctzt jedoch den Datenverkehr nicht vor Abh\u00f6rung und gew\u00e4hrleistet keine Vertraulichkeit der Anfragen. <\/p>\n Einige weitere Neuerungen: <\/p>\n\n