Nach zweijähriger Entwicklungszeit hat das ISC-Konsortium die erste stabile Version eines großen neuen Zweigs des BIND 9.18 DNS-Servers veröffentlicht. Der Support für Branch 9.18 wird im Rahmen eines erweiterten Supportzyklus drei Jahre lang bis zum 2. Quartal 2025 bereitgestellt. Der Support für den Zweig 9.11 endet im März und der Support für den Zweig 9.16 Mitte 2023. 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 Implementierung der Unterstützung für DNS über HTTPS (DoH, DNS über HTTPS) und DNS über TLS (DoT, DNS über TLS) sowie den XoT-Mechanismus (XFR-over-TLS) aus zur sicheren Übertragung von DNS-Inhalten. Zonen zwischen Servern (sowohl Sende- als auch Empfangszonen über XoT werden unterstützt). Mit den entsprechenden Einstellungen kann ein einzelner benannter Prozess nun nicht nur herkömmliche DNS-Anfragen bedienen, sondern auch Anfragen, die über DNS-over-HTTPS und DNS-over-TLS gesendet werden. Client-Unterstützung für DNS-over-TLS ist in das Dig-Dienstprogramm integriert, das zum Senden von Anfragen über TLS verwendet werden kann, wenn das Flag „+tls“ angegeben ist.
Die Implementierung des in DoH verwendeten HTTP/2-Protokolls basiert auf der Verwendung der nghttp2-Bibliothek, die als optionale Assembly-Abhängigkeit enthalten ist. Zertifikate für DoH und DoT können vom Benutzer bereitgestellt oder beim Start automatisch generiert werden.
Die Anforderungsverarbeitung mithilfe von DoH und DoT wird durch Hinzufügen der Optionen „http“ und „tls“ zur Listen-On-Direktive ermöglicht. 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;}; }
Eine der Funktionen der DoH-Implementierung in BIND 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 verwaltet werden durch anderes Personal. Die Unterstützung für unverschlüsseltes DNS-über-HTTP wird implementiert, um das Debuggen zu vereinfachen und als Schicht für die Weiterleitung an einen anderen Server im internen Netzwerk (zum Verschieben der Verschlüsselung auf einen separaten Server) zu dienen. Auf einem Remote-Server kann nginx zum Generieren von TLS-Verkehr verwendet werden, ähnlich wie die HTTPS-Bindung für Websites organisiert ist.
Ein weiteres Feature ist die Integration von DoH als allgemeines Transportmittel, das nicht nur zur Bearbeitung von Client-Anfragen an den Resolver, sondern auch bei der Kommunikation zwischen Servern, bei der Übertragung von Zonen durch einen autorisierenden DNS-Server und bei der Verarbeitung von Anfragen, die von anderen DNS unterstützt werden, verwendet werden kann Transporte.
Unter den Mängeln, die durch die Deaktivierung des Builds mit DoH/DoT oder die Verlagerung der Verschlüsselung auf einen anderen Server ausgeglichen werden können, sticht die allgemeine Komplikation der Codebasis hervor – ein integrierter HTTP-Server und eine TLS-Bibliothek werden hinzugefügt, die möglicherweise enthalten könnten Schwachstellen und fungieren als zusätzliche Vektoren für Angriffe. Außerdem steigt der Datenverkehr bei Verwendung von DoH.
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.
Einige weitere Neuerungen:
- Es wurden die Einstellungen „tcp-receive-buffer“, „tcp-send-buffer“, „udp-receive-buffer“ und „udp-send-buffer“ hinzugefügt, um die Größe der Puffer festzulegen, die beim Senden und Empfangen von Anforderungen über TCP und UDP verwendet werden. Auf ausgelasteten Servern trägt die Erhöhung der eingehenden Puffer dazu bei, zu verhindern, dass Pakete bei Verkehrsspitzen verworfen werden, und die Verringerung dieser Puffer trägt dazu bei, die Speicherverstopfung durch alte Anfragen zu beseitigen.
- Es wurde eine neue Protokollkategorie „rpz-passthru“ hinzugefügt, mit der Sie RPZ-Weiterleitungsaktionen (Response Policy Zones) separat protokollieren können.
- Im Abschnitt „Response-Policy“ wurde die Option „nsdname-wait-recurse“ hinzugefügt. Wenn sie auf „no“ gesetzt ist, werden die RPZ-NSDNAME-Regeln nur angewendet, wenn im Cache vorhandene autorisierende Nameserver für die Anfrage gefunden werden, andernfalls die Die RPZ-NSDNAME-Regel wird ignoriert, die Informationen werden jedoch im Hintergrund abgerufen und gelten für nachfolgende Anforderungen.
- Für Datensätze mit den Typen HTTPS und SVCB wurde die Verarbeitung des Abschnitts „ADDITIONAL“ implementiert.
- Benutzerdefinierte Aktualisierungsrichtlinien-Regeltypen hinzugefügt – krb5-subdomain-self-rhs und ms-subdomain-self-rhs, mit denen Sie die Aktualisierung von SRV- und PTR-Datensätzen einschränken können. Die Update-Policy-Blöcke bieten außerdem die Möglichkeit, die Anzahl der Datensätze individuell für jeden Typ zu begrenzen.
- Informationen zum Transportprotokoll (UDP, TCP, TLS, HTTPS) und DNS64-Präfixe zur Ausgabe des Dig-Dienstprogramms hinzugefügt. Für Debugging-Zwecke hat dig die Möglichkeit hinzugefügt, eine bestimmte Anforderungskennung anzugeben (dig +qid= ).
- Unterstützung für die OpenSSL 3.0-Bibliothek hinzugefügt.
- Um Probleme mit der IP-Fragmentierung bei der Verarbeitung großer DNS-Nachrichten zu beheben, die durch den DNS Flag Day 2020 identifiziert wurden, wurde Code aus dem Resolver entfernt, der die EDNS-Puffergröße anpasst, wenn keine Antwort auf eine Anfrage erfolgt. Die EDNS-Puffergröße ist jetzt für alle ausgehenden Anfragen auf konstant (edns-udp-size) eingestellt.
- Das Build-System wurde auf die Verwendung einer Kombination aus Autoconf, Automake und libtool umgestellt.
- Die Unterstützung für Zonendateien im „Map“-Format (Karte im Masterfile-Format) wurde eingestellt. Benutzern dieses Formats wird empfohlen, Zonen mit dem Dienstprogramm „named-compilezone“ in das Rohformat zu konvertieren.
- Die Unterstützung für ältere DLZ-Treiber (Dynamically Loadable Zones) wurde eingestellt und durch DLZ-Module ersetzt.
- Die Build-and-Run-Unterstützung für die Windows-Plattform wurde eingestellt. Der letzte Zweig, der unter Windows installiert werden kann, ist BIND 9.16.
Source: opennet.ru