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ü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 endet im März, und der Zweig 9.16 wird Mitte 2023 eingestellt. Für die Weiterentwicklung der Funktionen der nächsten stabilen Version von BIND wurde ein experimenteller Zweig BIND 9.19.0 gebildet.
Die Veröffentlichung von BIND 9.18.0 zeichnet sich durch die Implementierung der Unterstützung von Technologien wie "DNS über HTTPS" (DoH, DNS over HTTPS) und DNS über TLS (DoT, DNS over TLS) aus. Zudem wurde der Mechanismus XoT (XFR-over-TLS) für die sichere Übertragung von DNS-Zoneninhalten zwischen Servern eingeführt (unterstützt sowohl den Versand als auch den Empfang von Zonen über XoT). Bei entsprechender Konfiguration kann ein Named-Prozess nun nicht nur traditionelle DNS-Anfragen, sondern auch über DNS-over-HTTPS und DNS-over-TLS gesendete Anfragen bedienen. Die Client-Unterstützung für DNS-over-TLS ist in das Tool dig integriert, welches verwendet werden kann, um Anfragen über TLS mit der Option „+tls“ zu senden.
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. Die Zertifikate für DoH und DoT können vom Benutzer bereitgestellt oder während des Starts automatisch generiert werden.
Die Verarbeitung von Anfragen mit DoH und DoT erfolgt durch die Hinzufügung der Optionen „http“ und „tls“ in der Direktive listen-on. 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 Standardschnittstellenports 853 für DoT, 443 für DoH und 80 für DNS-over-HTTP können durch 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;}; }
Ein besonderes Merkmal der Implementierung von DoH in BIND ist die Möglichkeit, die Verschlüsselungsoperationen für 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ützung von unverschlüsseltem DNS-over-HTTP wurde zur Vereinfachung der Fehlersuche und als Stufe für die Weiterleitung an einen anderen Server im internen Netzwerk implementiert (um die Verschlüsselung auf einen separaten Server auszulagern). Als auslagernder Server kann nginx zur Generierung des TLS-Traffics verwendet werden, ähnlich wie die HTTPS-Bindung für Websites organisiert ist.
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 Übertragung von Zonen durch den autoritativen DNS-Server und bei der Verarbeitung aller Anfragen, die von anderen DNS-Transporten unterstützt werden.
Ein Nachteil, den man durch das Deaktivieren des DoH/DoT-Implementierung oder Verlagerung der Verschlüsselung auf einen anderen Server ausgleichen kann, ist die allgemeine Komplexität des Codes – ein eingebauter HTTP-Server und eine TLS-Bibliothek werden hinzugefügt, die möglicherweise Sicherheitsanfälligkeiten enthalten und zusätzliche Angriffsvektoren darstellen können. Auch bei der Verwendung von DoH erhöht sich der Datenverkehr.
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.
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 Buffer anzugeben, die beim Senden und Empfangen von Anfragen über TCP und UDP verwendet werden. Bei stark ausgelasteten Servern ermöglicht die Erhöhung der eingehenden Buffer, Paketverluste während Verkehrsspitzen zu vermeiden, während die Verringerung hilft, die Speicherung alter Anfragen im Speicher zu verhindern.
- Eine neue Log-Kategorie „rpz-passthru“ wurde hinzugefügt, um die Aktionen des Weiterleitens von RPZ (Response Policy Zones) gesondert zu protokollieren.
- In der Sektion response-policy wurde die Option «nsdname-wait-recurse» hinzugefügt. Wenn diese auf «no» gesetzt ist, gelten die Regeln der RPZ NSDNAME nur, wenn für die Anfrage vorhandene, im Cache gespeicherte autoritative Nameserver gefunden werden. Andernfalls wird die Regel RPZ NSDNAME ignoriert, aber die Informationen werden im Hintergrund abgerufen und auf nachfolgende Anfragen angewendet.
- Für Einträge mit den Typen HTTPS und SVCB wurde die Verarbeitung der Sektion «ADDITIONAL» implementiert.
- Anpassbare Regeltypen für update-policy wurden hinzugefügt: krb5-subdomain-self-rhs und ms-subdomain-self-rhs. Diese ermöglichen es, die Aktualisierung von SRV- und PTR-Einträgen einzuschränken. In den update-policy-Blöcken wurde zudem die Möglichkeit hinzugefügt, individuelle Einschränkungen für die Anzahl der Einträge je Typ festzulegen.
- Die Ausgabe des Tools dig enthält jetzt Informationen über das Transportprotokoll (UDP, TCP, TLS, HTTPS) und die DNS64-Präfixe. Zu Debugging-Zwecken wurde die Möglichkeit hinzugefügt, eine spezifische Anfragen-ID anzugeben (dig +qid=).
- Die Unterstützung für die OpenSSL 3.0-Bibliothek 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 beheben, wurde der Code, der die EDNS-Puffergröße in der Resolver-Software anpasst, entfernt, wenn keine Antwort auf die Anfrage erfolgt. Die EDNS-Puffergröße wird nun konstant (edns-udp-size) für alle ausgehenden Anfragen festgelegt.
- Das Build-System wurde auf eine Kombination aus autoconf, automake und libtool umgestellt.
- Die Unterstützung für Zonendateien im „map“-Format (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 für alte DLZ-Treiber (Dynamically Loadable Zones) wurde eingestellt; stattdessen werden jetzt DLZ-Module verwendet.
- Die Unterstützung für den Build und das Ausführen auf der Windows-Plattform wurde eingestellt. Der letzte Branch, der unter Windows installiert werden kann, bleibt BIND 9.16.
Quelle: opennet.ru
