Zurück zum Blog
dns Veröffentlicht: AEU DNS Newsroom

Stork 2.6 vereinheitlicht die Nachverfolgung von DHCP leases und DNS transfers

Stork 2.6 vereinheitlicht die Nachverfolgung von DHCP leases und DNS transfers
KI-generiertes Bild

Stork 2.6 ergänzt serverübergreifende Suchen nach DHCP leases, die Überwachung von BIND 9 zone transfers, die Anmeldung über OpenID Connect und die Verwaltung des Kea Configuration Backend.

Stork 2.6 erweitert das Open-Source-Verwaltungstool um eine konsolidierte Nachverfolgung von leases des Dynamic Host Configuration Protocol (DHCP) und die Überwachung von zone transfers des Domain Name System (DNS). DHCP weist Geräten automatisch Netzwerkadressen zu, während DNS Internetnamen an die Systeme weiterleitet, die sie bereitstellen. ISC bezeichnet Version 2.6 als stabile, für den Produktiveinsatz geeignete Version, weist jedoch auch auf zwei bekannte Probleme hin, die Administratoren vor der Bereitstellung prüfen sollten.

Die Version umfasst vier wesentliche Neuerungen: die Nachverfolgung von leases über mehrere Kea DHCP-Server hinweg, die Authentifizierung über OpenID Connect, die Überwachung von BIND 9 DNS zone transfers und die Unterstützung des Kea Configuration Backend. ISC hat außerdem eine wichtige Abhängigkeit der Benutzeroberfläche ersetzt und mehrere sicherheitsbezogene Änderungen eingeführt.

Die konsolidierte Nachverfolgung von leases soll Administratoren eine einheitliche Übersicht über Adresszuweisungen in einer potenziell großen Kea-Umgebung geben. Ein lease ist die vorübergehende Zuweisung einer IP-Adresse an ein Gerät. Wenn die Funktion aktiviert ist, erfassen Stork agents Informationen zu leases aus den lease-Dateien erkannter Kea-Instanzen und senden sie an den zentralen Server. Stork erstellt anschließend eine durchsuchbare Datenbank, die leases von allen überwachten Servern umfasst. Die aktuelle Implementierung funktioniert ausschließlich mit dem memfile backend von Kea, das lease-Daten in Dateien speichert.

Administratoren können die erfassten leases sortieren, filtern und durchsuchen, einschließlich DHCPv6 leases, die mit der neueren Version des Internet Protocol verwendet werden, und einen einzelnen record öffnen, um weitere Einzelheiten anzuzeigen. Laut ISC soll das umfassendere Projekt Betreiber dabei unterstützen, zu erkennen, welche Clients leases besitzen, Zuweisungsprobleme zu untersuchen, leases eines bestimmten Clients zu finden, die lease-Historie eines Clients zu prüfen, Geräte zu identifizieren, die erstmals einen lease erhalten, und unter bestimmten Umständen eine vorzeitige Verlängerung oder Entfernung zu beschleunigen. Nicht alle diese Ziele werden für diese Version als fertiggestellte Funktionen beschrieben. ISC sucht nach weiteren Anwendungsfällen, um die künftige Diagnose weiterzuentwickeln, insbesondere für Netzwerke mit vielen subnets und einer großen Zahl von leases.

Die zweite wesentliche Änderung ist OpenID Connect (OIDC), ein Standard, mit dem sich ein Dienst auf einen externen Identitätsanbieter verlassen kann, um die Identität eines Benutzers zu bestätigen. Stork unterstützte bisher in seiner eigenen Datenbank gespeicherte Zugangsdaten sowie LDAP, ein System, das häufig zur Verwaltung von Benutzerkonten in Organisationen verwendet wird. Wenn OIDC konfiguriert ist, fungiert der Stork-Server als relying party und übergibt die Authentifizierung an einen externen Anbieter. Dadurch kann die Anwendung mit Single Sign-On (SSO) verbunden werden, bei dem ein einziges Organisationskonto für mehrere Dienste verwendet wird. Zudem kann der externe Anbieter eine Multi-Faktor-Authentifizierung verlangen.

Für DNS-Betreiber führt Stork 2.6 eine zentralisierte Überwachung von BIND 9 zone transfers ein. Ein zone transfer kopiert authoritative DNS records, also die records, die die offiziellen Antworten für eine Domain liefern, zwischen DNS-Servern. Zur Diagnose eines festhängenden oder ins Stocken geratenen transfers mussten Betreiber bisher üblicherweise BIND-Logs untersuchen und Informationen aus mehreren Quellen zusammentragen.

Stork agents können nun records zu gestarteten, abgeschlossenen und fehlgeschlagenen transfers von mehreren BIND 9-Instanzen abrufen. Der Server führt diese Ereignisse zusammen und stellt eine einheitliche Liste für die überwachte Umgebung bereit. Jeder record enthält einen Zeitstempel mit Millisekundengenauigkeit und kann Startzeit, Dauer, sendenden Server und empfangenden Server anzeigen. Bei fehlgeschlagenen transfers kann Stork zusätzliche Details aus den relevanten Log-Meldungen bereitstellen. So können Betreiber direkt zwischen einer erfolgreichen Synchronisierung und nicht abgeschlossenen transfers unterscheiden.

Die Version macht Stork außerdem mit dem Kea Configuration Backend kompatibel, das nahezu die gesamte Kea-Konfiguration in einer oder mehreren Datenbanken speichert. Zu den potenziellen Vorteilen gehören die Wiederverwendung identischer Konfigurationsabschnitte auf mehreren Servern, die Pflege einer zentralen verlässlichen Datenquelle, die Anwendung von Änderungen über eine API mit Logikprüfungen in Echtzeit, die Integration von Drittanbieter-Tools oder interner Automatisierung sowie die Nutzung von Datenbankeigenschaften für Parallelität, Konsistenz und atomare Änderungen. Die Datenbank kann zudem Berichterstellung und Replikation unterstützen, um Fehlertoleranz in Echtzeit zu ermöglichen.

ISC weist auch auf Nachteile hin. Die Einführung des backend kann umfangreiche Vorbereitungen für Integration oder Automatisierung erfordern. In den unterstützten Szenarien müssen die meisten Konfigurationsarbeiten über die API erfolgen, und diese API steht nur ISC-Kunden mit einem kostenpflichtigen Supportvertrag zur Verfügung. Mit früheren Versionen konnten in diesem backend gespeicherte Konfigurationen nicht über Stork verwaltet werden.

Stork 2.6 kann im backend gespeicherte subnets erstellen, ändern und löschen, wenn die hook libraries `cb_cmds` und `subnet_cmds` geladen sind. Ein subnet ist ein definierter Abschnitt eines IP-Netzwerks, während eine hook library Kea um zusätzliche Befehle oder Verhaltensweisen erweitert. Daemons, die dieselbe backend-Datenbank und denselben server tag verwenden, werden im subnet-Formular zusammengefasst, sodass ein Administrator sie nicht einzeln auf widersprüchliche Weise konfigurieren kann. Administratoren können die mit einem subnet verknüpften server tags auswählen und damit festlegen, welche Server es erhalten. Hilfetexte unterscheiden zwischen Vorgängen, die die JSON-Konfigurationsdatei verändern, und Vorgängen, die Änderungen an der backend-Datenbank vornehmen.

ISC hat PrimeNG ersetzt, die bisher für Tabellen, Seitennummerierung, Schaltflächen und andere Bedienelemente verwendete Komponentenbibliothek der Benutzeroberfläche. PrimeTek kündigte Ende Juni an, die Arbeit an der Open-Source-Bibliothek PrimeNG einzustellen und zu einem kommerziellen Modell überzugehen. ISC erwog, ausgewählte Komponenten selbst zu pflegen, auf Angular Material umzusteigen und die Benutzeroberfläche mit HTMX neu zu entwickeln. Letztlich entschied sich ISC für Optimus-UI, einen von der Community über OpenNG gepflegten Open-Source-fork, und gibt an, einen jährlichen finanziellen Beitrag für diese Organisation einzuplanen.

Im Rahmen der Sicherheitswartung experimentiert das Stork-Team angesichts der Vielzahl gemeldeter Schwachstellen in seinem Software-Ökosystem mit wöchentlichen Aktualisierungen von Abhängigkeiten. Laut ISC enthält Version 2.6.0 außerdem weitere Sicherheitsverbesserungen und Fehlerbehebungen, die in den release notes dokumentiert sind. Da weiterhin zwei bekannte Probleme bestehen, sollten Administratoren sowohl die release notes als auch die Stork Known Issues List lesen, das Upgrade mit ihrer eigenen Konfiguration testen und eine Wiederherstellungsmöglichkeit vorhalten, bevor sie es in einer Produktivumgebung einsetzen.

Der Quellcode ist über den Downloadbereich von ISC verfügbar. ISC vertreibt über sein Cloudsmith repository außerdem Pakete für Debian, Alpine und RPM-basierte Systeme. Ein Quickstart Guide und ein Administrator Reference Manual stehen als Hilfe für die Bereitstellung zur Verfügung. Professioneller Stork-Support wird als Bestandteil eines Supportvertrags für Kea DHCP angeboten. ISC führt Bronze mit E-Mail-Support während der Geschäftszeiten, Silver mit rund um die Uhr verfügbarem E-Mail- und Telefonsupport im Rahmen von service-level agreements sowie Gold mit schnelleren Reaktionszeiten auf. Silver und Gold umfassen den Role-Based Access Control hook. Die Abonnementkosten richten sich nach der Größe der Bereitstellung, gemessen an der Zahl gleichzeitiger leases.

Für Organisationen, die externe Unterstützung beim Betrieb solcher Systeme benötigen, bietet AEU-I sicherheitsorientierte IT-, Infrastruktur- und Beratungsleistungen an.

Begriffe erklärt

DHCP
Das Dynamic Host Configuration Protocol weist verbundenen Geräten automatisch Netzwerkeinstellungen und IP-Adressen zu.
DNS
Das Domain Name System verbindet für Menschen lesbare Domainnamen mit den von Computern verwendeten Netzwerkadressen.
lease
Ein lease ist die vorübergehende Zuweisung einer IP-Adresse an ein Gerät in einem Netzwerk.
OpenID Connect
OpenID Connect ermöglicht einer Anwendung, die Identität eines Benutzers über einen externen Kontoanbieter zu überprüfen.
Single Sign-On
Single Sign-On ermöglicht den Zugriff auf mehrere Dienste mit einem einzigen Organisationskonto.
zone transfer
Ein zone transfer kopiert die offiziellen DNS records einer Domain von einem authoritative DNS-Server auf einen anderen.
Kea Configuration Backend
Das Kea Configuration Backend speichert die Konfiguration von DHCP-Servern in einer oder mehreren Datenbanken, anstatt sich ausschließlich auf lokale Dateien zu stützen.
subnet
Ein subnet ist ein definierter kleinerer Abschnitt eines IP-Netzwerks.

So schützen Sie sich

  1. Lesen Sie vor der Installation des Updates in einem Produktivnetzwerk die Liste der bekannten Probleme und die release notes zu Stork 2.6.0.
  2. Testen Sie das Upgrade zunächst auf einem nicht produktiv genutzten System und prüfen Sie anschließend, ob Suchen nach leases und DNS transfer records korrekt angezeigt werden.
  3. Erstellen Sie vor Änderungen an der Installation eine wiederherstellbare Kopie Ihrer aktuellen Stork- und Kea-Konfiguration.
  4. Wenn Ihre Organisation OpenID Connect verwendet, bitten Sie Ihren Administrator, beim externen Anmeldeanbieter eine Multi-Faktor-Authentifizierung vorzuschreiben.
  5. Prüfen Sie, ob die erforderlichen Erweiterungen cb_cmds und subnet_cmds geladen sind, bevor Sie versuchen, im Kea Configuration Backend gespeicherte subnets zu bearbeiten.
  6. Beschränken Sie den Zugriff auf das Stork-Dashboard auf Mitarbeiter, die Netzwerkzuweisungen tatsächlich einsehen oder ändern müssen.
Holen Sie sich privates, verschlüsseltes DNS