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ützung für den Zweig 9.18 wird bis zum zweiten Quartal 2025 im Rahmen eines erweiterten Wartungszyklus bereitgestellt. Die Unterstützung für den Zweig 9.11 wird im März eingestellt, während die Unterstützung für den Zweig 9.16 Mitte 2023 endet. Um die Funktionalität der nächsten stabilen Version von BIND zu entwickeln, wurde ein experimenteller Zweig BIND 9.19.0 gebildet.
Die Veröffentlichung von BIND 9.18.0 zeichnet sich durch die Unterstützung der Technologien "DNS über HTTPS" (DoH, DNS over HTTPS) und DNS über TLS (DoT, DNS over TLS) sowie durch den Mechanismus XoT (XFR-over-TLS) aus, der eine sichere Übertragung von DNS-Zonendaten zwischen Servern ermöglicht (sowohl für den Versand als auch den Empfang von Zonen über XoT). Bei entsprechender Konfiguration kann ein Prozess named jetzt nicht nur traditionelle DNS-Anfragen, sondern auch Anfragen, die über DNS-over-HTTPS und DNS-over-TLS gesendet werden, bedienen. Die Clientunterstützung für DNS-over-TLS ist in das Tool dig integriert, das verwendet werden kann, um Anfragen über TLS zu senden, indem das Flag „+tls“ angegeben wird.
Die Implementierung des HTTP/2-Protokolls, das in DoH verwendet wird, basiert auf der Verwendung der nghttp2-Bibliothek, die zu den optionalen Build-Abhängigkeiten gehört. Zertifikate für DoH und DoT können vom Benutzer bereitgestellt oder automatisch beim Start generiert werden.
Die Verarbeitung von Anfragen mit DoH und DoT wird durch das Hinzufügen der Optionen „http“ und „tls“ in der Direktive listen-on aktiviert. Um unverschlüsseltes DNS-over-HTTP zu unterstützen, muss in den Einstellungen „tls none“ angegeben werden. Die Schlüssel werden im Abschnitt „tls“ definiert. Die Standardnetzportnummern 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"; 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;}; }
Eine Besonderheit der Umsetzung von DoH in BIND ist die Möglichkeit, die Verschlüsselungsoperationen für 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ützung von unverschlüsseltem DNS-over-HTTP wurde implementiert, um das Debuggen zu erleichtern und als Schicht für die Weiterleitung zu einem anderen Server im internen Netzwerk (zur Auslagerung der Verschlüsselung auf einen separaten Server). Auf dem externen Server kann nginx zur Erzeugung des TLS-Verkehrs verwendet werden, ähnlich wie die HTTPS-Bindung für Websites organisiert ist.
Ein weiteres Merkmal ist die Integration von DoH als allgemeinem Transport, der nicht nur für die Verarbeitung von Clientanfragen an Resolver verwendet werden kann, sondern auch beim Austausch von Daten zwischen Servern, bei der Übertragung von Zonen durch einen autoritativen DNS-Server und bei der Verarbeitung aller Anfragen, die von anderen DNS-Transporten unterstützt werden.
Zu den Nachteilen, die durch das Ausschalten des Builds mit DoH/DoT oder die Auslagerung der Verschlüsselung auf einen anderen Server ausgeglichen werden können, gehört die allgemeine Komplexität des Codes - ein integrierter HTTP-Server und eine TLS-Bibliothek werden hinzugefügt, die potenziell Schwachstellen enthalten und zusätzliche Angriffsrouten darstellen können. Außerdem steigt der Datenverkehr bei der Verwendung von DoH.
Es sei daran erinnert, dass DNS-over-HTTPS nützlich sein kann, um das Auslaufen von Informationen über angeforderte Hostnamen durch die DNS-Server der Anbieter zu verhindern, gegen MITM-Angriffe und DNS-Verkehrsmanipulation (z. B. beim Anschluss an öffentliche Wi-Fi-Netzwerke) vorzugehen sowie DNS-Sperren zu widerstehen (DNS-over-HTTPS kann nicht die VPN Blockaden umgehen, die auf DPI-Ebene implementiert sind) oder um den Betrieb zu organisieren, wenn eine direkte Ansprache der DNS-Server nicht möglich ist (z. B. beim Arbeiten über Proxys). Während 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 des Hosts in den HTTPS-Verkehr gekapselt und an den HTTP-Server gesendet, auf dem der Resolver die Anfragen über die Web-API verarbeitet.
DNS over TLS unterscheidet sich von DNS over HTTPS durch die Verwendung des Standardprotokolls DNS (normalerweise wird der Netzwerkport 853 verwendet), das in einen verschlüsselten Kommunikationskanal eingewickelt ist, der mithilfe des TLS-Protokolls mit Hostvalidierung über TLS/SSL-Zertifikate, die von einer Zertifizierungsstelle signiert wurden, eingerichtet wird. 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 gewährleistet keine Vertraulichkeit der Anfragen.
Einige weitere Neuerungen:
- Es wurden Einstellungen für tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer und udp-send-buffer hinzugefügt, um die Größen der Puffer zu definieren, die bei der Übertragung und dem Empfang von Anfragen über TCP und UDP verwendet werden. Auf stark belasteten Servern ermöglicht eine Erhöhung der eingehenden Puffer, Paketverluste während Spitzenzeiten zu vermeiden, während eine Verringerung dabei helfen kann, Speicherplatz von alten Anfragen zu befreien.
- Eine neue Protokollkategorie "rpz-passthru" wurde hinzugefügt, die es ermöglicht, die Aktionen bei der Durchleitung von RPZ (Response Policy Zones) getrennt zu protokollieren.
- Im Abschnitt response-policy wurde die Option „nsdname-wait-recurse“ hinzugefügt. Wenn diese auf „no“ gesetzt ist, gelten die RPZ NSDNAME-Regeln nur, wenn für die Anfrage im Cache befindliche autoritative Nameserver gefunden werden. Andernfalls wird die RPZ NSDNAME-Regel ignoriert, jedoch werden die Informationen im Hintergrund extrahiert und auf nachfolgende Anfragen angewendet.
- Für Einträge mit den Typen HTTPS und SVCB wurde die Verarbeitung des Abschnitts „ADDITIONAL“ implementiert.
- Es wurden anpassbare Regeltypen für die update-policy hinzugefügt – krb5-subdomain-self-rhs und ms-subdomain-self-rhs, die eine Einschränkung der Aktualisierung von SRV- und PTR-Einträgen ermöglichen. In den update-policy-Blöcken wurde auch die Möglichkeit hinzugefügt, die Anzahl der Einträge, spezifisch für jeden Typ, zu beschränken.
- Der Ausgabe der dig-Utility wurden Informationen über das Transportprotokoll (UDP, TCP, TLS, HTTPS) und DNS64-Präfixe hinzugefügt. Für Debugging-Zwecke wurde in dig die Möglichkeit hinzugefügt, eine spezifische Anfrage-ID anzugeben (dig +qid=).
- Unterstützung für die OpenSSL-Bibliothek 3.0 wurde hinzugefügt.
- Um Probleme mit der IP-Fragmentierung bei der Verarbeitung von großen DNS-Nachrichten, die durch die Initiative DNS Flag Day 2020 gekennzeichnet sind, zu lösen, wurde der Code aus dem Resolver entfernt, der die Größe des EDNS-Puffers bei fehlender Antwort auf eine Anfrage angepasst hat. Die Größe des EDNS-Puffers wird nun konstant (edns-udp-size) für alle ausgehenden Anfragen festgelegt.
- Das Assemblierungssystem wurde auf die Verwendung einer Kombination aus autoconf, automake und libtool umgestellt.
- Die Unterstützung für Zonendateien im Format „map“ (masterfile-format map) wurde eingestellt. Benutzern dieses Formats wird empfohlen, die Zonen mit dem Tool named-compilezone in das Raw-Format zu konvertieren.
- Die Unterstützung alter DLZ-Treiber (Dynamically Loadable Zones) wurde eingestellt, ersetzt durch DLZ-Module.
- Die Unterstützung für den Aufbau und die Ausführung auf der Windows-Plattform wurde eingestellt. Der letzte Zweig, der unter Windows installiert werden kann, bleibt BIND 9.16.
Quelle: opennet.ru
