Nach zwei Jahren Entwicklung hat das Konsortium ISC die erste stabile Version des neuen bedeutenden Zweigs des DNS-Servers BIND 9.18 vorgestellt. Die Unterst\u00fctzung 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 wird im M\u00e4rz eingestellt, w\u00e4hrend die Unterst\u00fctzung f\u00fcr den Zweig 9.16 Mitte 2023 endet. Um die Funktionalit\u00e4t der n\u00e4chsten stabilen Version von BIND zu entwickeln, wurde ein experimenteller Zweig BIND 9.19.0 gebildet. <\/p>\n
Die Ver\u00f6ffentlichung von BIND 9.18.0 ist bemerkenswert durch die Implementierung der Unterst\u00fctzung f\u00fcr Technologien wie \u201eDNS \u00fcber HTTPS\u201c (DoH, DNS over HTTPS) und DNS \u00fcber TLS (DoT, DNS over TLS) sowie des XoT (XFR-over-TLS) Mechanismus f\u00fcr die sichere \u00dcbertragung von DNS-Zoneninhalten zwischen Servern (unterst\u00fctzt sowohl die \u00dcbertragung als auch den Empfang von Zonen \u00fcber XoT). Bei entsprechender Konfiguration kann ein Prozess namens named nun nicht nur traditionelle DNS-Anfragen bedienen, sondern auch Anfragen, die \u00fcber DNS over HTTPS und DNS over TLS gesendet werden. Die Client-Unterst\u00fctzung f\u00fcr DNS-over-TLS ist in das Tool dig integriert, das 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. Zertifikate f\u00fcr DoH und DoT k\u00f6nnen vom Benutzer bereitgestellt oder automatisch beim Start generiert werden. <\/p>\n
Die Verarbeitung von Anfragen mit DoH und DoT wird durch das Hinzuf\u00fcgen der Optionen \u201ehttp\u201c und \u201etls\u201c zur Direktive listen-on aktiviert. Um unverschl\u00fcsseltes DNS-over-HTTP zu unterst\u00fctzen, muss in den Einstellungen \u201etls none\u201c angegeben werden. Die Schl\u00fcssel werden im Abschnitt \u201etls\u201c definiert. Die Standard-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
Eine Besonderheit der Umsetzung von DoH in BIND ist die M\u00f6glichkeit, die Verschl\u00fcsselungsoperationen f\u00fcr TLS auf einen anderen Server auszulagern. Dies kann erforderlich sein, wenn die TLS-Zertifikate auf einem anderen System (z. B. in einer Infrastruktur mit Web-Servern) gespeichert und von anderem Personal verwaltet werden. Die Unterst\u00fctzung von unverschl\u00fcsseltem DNS-over-HTTP wurde implementiert, um das Debuggen zu erleichtern und als Schicht f\u00fcr die Weiterleitung zu einem anderen Server im internen Netzwerk (zur Auslagerung der Verschl\u00fcsselung auf einen separaten Server). Auf dem externen Server kann nginx zur Erzeugung des TLS-Verkehrs verwendet werden, \u00e4hnlich wie die HTTPS-Bindung f\u00fcr Websites organisiert ist. <\/p>\n
Ein weiteres Merkmal ist die Integration von DoH als allgemeinem Transport, der nicht nur f\u00fcr die Verarbeitung von Clientanfragen an Resolver verwendet werden kann, sondern auch beim Austausch von Daten zwischen Servern, bei der \u00dcbertragung von Zonen durch einen 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 Ausschalten der DoH\/DoT-Bauweise oder die Auslagerung der Verschl\u00fcsselung auf einen anderen Server kompensiert werden k\u00f6nnen, geh\u00f6rt die allgemeine Verkomplizierung des Codes \u2014 es wird ein integrierter HTTP-Server und eine TLS-Bibliothek hinzugef\u00fcgt, die potenziell Schwachstellen enthalten und zus\u00e4tzliche Angriffsvektoren darstellen k\u00f6nnen. Auch der Datenverkehr nimmt bei der Verwendung von DoH zu. <\/p>\n
Es sei daran erinnert, dass DNS-over-HTTPS n\u00fctzlich sein kann, um das Auslaufen von Informationen \u00fcber angeforderte Hostnamen durch die DNS-Server der Anbieter zu verhindern, gegen MITM-Angriffe und DNS-Verkehrsmanipulation (z. B. beim Anschluss an \u00f6ffentliche Wi-Fi-Netzwerke) vorzugehen sowie DNS-Sperren zu widerstehen (DNS-over-HTTPS kann nicht die VPN<\/a> Blockaden umgehen, die auf DPI-Ebene implementiert sind) oder um den Betrieb zu organisieren, wenn eine direkte Ansprache der DNS-Server nicht m\u00f6glich ist (z. B. beim Arbeiten \u00fcber Proxys). W\u00e4hrend im Normalfall DNS-Anfragen direkt an die in der Systemkonfiguration festgelegten DNS-Server gesendet werden, wird im Fall von DNS-over-HTTPS die Anfrage zur Bestimmung IP-Adressen<\/a> des Hosts in den HTTPS-Verkehr gekapselt und an den HTTP-Server gesendet, auf dem der Resolver die Anfragen \u00fcber die Web-API verarbeitet. <\/p>\n \u201eDNS \u00fcber TLS\u201c unterscheidet sich von \u201eDNS \u00fcber HTTPS\u201c durch die Verwendung des Standardprotokolls DNS (normalerweise wird Port 853 verwendet), das in einen verschl\u00fcsselten Kommunikationskanal eingewickelt ist, der mithilfe des TLS-Protokolls mit Hostvalidierung \u00fcber TLS\/SSL-Zertifikate, die von einer Zertifizierungsstelle beglaubigt sind, organisiert wird. Der bestehende Standard DNSSEC nutzt Verschl\u00fcsselung lediglich zur Authentifizierung von Client und Server, sch\u00fctzt jedoch den Datenverkehr nicht vor Abh\u00f6rung und garantiert nicht die Vertraulichkeit von Anfragen. <\/p>\n Einige weitere Neuerungen: <\/p>\n\n