DNS-Zonen per API und Terraform konsistent verwalten

TL;DR

DNS-Änderungen gehören in denselben kontrollierten Prozess wie andere Infrastrukturänderungen. Mit der ayedo Edge Cloud lassen sich externe DNS-Zonen über API und Terraform deklarativ verwalten. Versionskontrolle, Reviews und reproduzierbare Ausführung reduzieren manuelle Fehler und schaffen klare Verantwortlichkeiten zwischen Plattform- und Anwendungsteams.

Einleitung

DNS wird in vielen Unternehmen noch direkt im Webinterface gepflegt. Das funktioniert, solange wenige Personen einzelne Einträge ändern. Mit wachsender Anzahl von Services, Umgebungen und Teams entstehen jedoch schwer nachvollziehbare Zustände: Ein Record wurde manuell angepasst, eine Änderung nicht dokumentiert oder zwischen Test und Produktion unterschiedlich umgesetzt. Der technische Fehler liegt meist nicht im DNS selbst, sondern im fehlenden Änderungsprozess. Wer DNS mit Terraform verwalten will, behandelt Zonen und Records als versionierte Infrastruktur. Die DNS-API der ayedo Edge Cloud bildet dabei die technische Schnittstelle, während Terraform die gewünschte Konfiguration beschreibt und ihre Umsetzung in bestehende Platform-Engineering-Prozesse integriert.

1. DNS-Zonen als deklarativen Infrastrukturzustand beschreiben

Bei einer imperativen Änderung wird ein einzelner DNS-Record direkt angelegt, verändert oder gelöscht. Der Operator denkt in Aktionen: „Erzeuge diesen Eintrag.“ Eine deklarative Konfiguration beschreibt dagegen den gewünschten Zustand. Terraform vergleicht diesen Zustand mit der vorhandenen Konfiguration und ermittelt daraus die erforderlichen Änderungen.

Für DNS-Zonen ist dieser Unterschied relevant, weil Records nicht isoliert betrachtet werden sollten. Namen, Typen, Zielwerte und weitere Eigenschaften bilden gemeinsam die Konfiguration einer Zone. Eine deklarative Verwaltung macht sichtbar, welche Einträge existieren sollen und welche nicht mehr vorgesehen sind. Das erleichtert Reviews und reduziert das Risiko, dass veraltete Records unbemerkt bestehen bleiben.

Die ayedo Edge Cloud stellt für die Verwaltung externer DNS-Zonen eine API bereit, die über Terraform genutzt werden kann. Damit wird DNS nicht zu einem Sonderprozess neben der übrigen Infrastruktur. Zonen können wie andere Ressourcen beschrieben, geplant und kontrolliert ausgerollt werden. Die konkrete Konfiguration bleibt dabei im Repository und nicht ausschließlich im Zustand eines einzelnen Webinterfaces.

2. Versionskontrolle schafft nachvollziehbare Änderungen

Der zentrale Vorteil von Infrastructure as Code ist nicht nur die Automatisierung, sondern die Nachvollziehbarkeit. Eine Änderung am DNS wird als Diff sichtbar: Welcher Record wurde ergänzt, welcher Zielwert geändert und welcher Eintrag entfernt? Diese Information gehört in den normalen Review-Prozess und kann mit einer fachlichen Begründung, einem Ticket oder einer Änderung an der zugehörigen Anwendung verknüpft werden.

Für Platform-Engineering-Teams entsteht dadurch eine klare Trennung zwischen Definition und Ausführung. Das Repository enthält die gewünschte Konfiguration. Terraform erzeugt daraus einen Plan. Erst nach Prüfung wird die Änderung angewendet. So lässt sich beispielsweise kontrollieren, ob ein neuer Name auf das vorgesehene Ziel zeigt oder ob ein bestehender Record versehentlich überschrieben wird.

Auch bei Störungen ist diese Historie wertvoll. Wenn eine DNS-Änderung zu unerwartetem Verhalten führt, kann das Team den Zeitpunkt und Inhalt der Änderung nachvollziehen und gezielt korrigieren. Ein Rollback ist dabei kein beliebiges Zurücksetzen, sondern die Wiederherstellung einer bekannten Konfiguration aus der Versionshistorie. Das verbessert die Betriebsfähigkeit, ersetzt aber keine fachliche Prüfung von TTLs, Delegationen oder abhängigen Systemen.

3. API und Terraform sinnvoll in Betriebsprozesse integrieren

Terraform sollte nicht als weiterer manueller Zugang neben der API und dem Portal betrieben werden. Entscheidend ist eine definierte Zuständigkeit: Welche Änderungen werden ausschließlich über Terraform vorgenommen, und welche Fälle dürfen direkt über die API erfolgen? Ohne diese Regel entstehen zwei Wahrheiten. Terraform kennt dann einen Zustand, während die DNS-Zone bereits manuell verändert wurde.

Für reguläre Änderungen empfiehlt sich ein standardisierter Ablauf: Konfiguration anpassen, Plan erzeugen, Änderungen prüfen, Anwendung ausführen und Ergebnis dokumentieren. Automatisierte Prüfungen können zusätzlich Format, Namenskonventionen oder erlaubte Zonentypen kontrollieren. Der [Terraform]-State muss dabei zuverlässig und für die zuständigen Teams zugänglich verwaltet werden. Andernfalls können parallele Änderungen zu Konflikten führen.

Direkte API-Änderungen bleiben in bestimmten Situationen sinnvoll, etwa bei einer begrenzten operativen Korrektur oder wenn ein automatisierter Prozess bewusst außerhalb des [Terraform]-Lebenszyklus arbeitet. Solche Ausnahmen müssen jedoch sichtbar bleiben. Nach einer manuellen Änderung sollte die deklarative Konfiguration zeitnah angepasst werden. Sonst überschreibt der nächste [Terraform]-Lauf möglicherweise eine beabsichtigte Änderung oder entfernt sie unbeabsichtigt.

4. Trennung von Plattformverantwortung und Service-Lifecycle

DNS ist häufig eng mit dem Lebenszyklus einer Anwendung verbunden, wird aber nicht immer vom selben Team betrieben. Ein Platform-Team kann die DNS-Zonen und den technischen Rahmen verwalten, während Anwendungsteams ihre benötigten Records über kontrollierte Schnittstellen oder Pull Requests einbringen. Diese Trennung reduziert direkte Zugriffe und macht Verantwortlichkeiten eindeutig.

Dabei sollte die Verwaltung nicht auf ayedo Managed Kubernetes beschränkt werden. Die ayedo Edge Cloud kann als vorgelagerte Plattform auch vor eigenen oder bei anderen Providern betriebenen [Kubernetes]-Clustern eingesetzt werden. DNS-Konfiguration und Clusterbetrieb bleiben damit getrennte Verantwortungsbereiche. Ein Service kann in einer Compute-Umgebung laufen, während sein öffentlicher DNS-Einstieg zentral über die Edge Cloud verwaltet wird.

Diese Entkopplung ist auch aus Betriebssicht relevant. Ein Clusterwechsel muss nicht automatisch eine manuelle DNS-Migration auslösen, wenn die DNS-Zone unabhängig versioniert und über die API verwaltet wird. Zugleich darf die technische Trennung nicht zu unklaren Übergaben führen: Für jeden Record sollten Zweck, Zielsystem und zuständiges Team bekannt sein. So wird DNS mit Terraform zu einem kontrollierten Bestandteil des Service-Lifecycles statt zu einer isolierten Administrationsaufgabe.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt mehrere öffentliche Services in unterschiedlichen [Kubernetes]-Clustern. Die DNS-Zone wird zentral in der ayedo Edge Cloud verwaltet. Ein neuer Service benötigt einen zusätzlichen Namen und einen Record auf den vorgesehenen öffentlichen Einstieg.

Das Anwendungsteam erstellt eine Änderung im Repository. Terraform zeigt im Plan ausschließlich den neuen Record. Das Platform-Team prüft Ziel, Namenskonvention und die Auswirkungen auf den Service-Lifecycle. Nach dem Review wird die Änderung angewendet und ist anschließend über Git-Historie und [Terraform]-State nachvollziehbar.

Würde derselbe Record direkt im Portal angelegt, wäre der operative Effekt zunächst identisch. Der Unterschied zeigt sich später: Ohne deklarative Konfiguration fehlen standardisierte Prüfung, reproduzierbare Wiederherstellung und eine belastbare Verbindung zur Anwendungsänderung.

FAQ

Kann DNS vollständig ohne manuelle Änderungen verwaltet werden?

Ja, reguläre Änderungen können über Terraform und die ayedo Edge Cloud API automatisiert werden. Ausnahmen sollten dokumentiert und anschließend mit der deklarativen Konfiguration abgeglichen werden.

Was passiert bei einer manuellen Änderung außerhalb von Terraform ?

Terraform erkennt eine Abweichung zwischen gewünschtem und tatsächlichem Zustand. Vor dem nächsten Apply sollte geklärt werden, ob die manuelle Änderung übernommen oder zurückgesetzt werden soll.

Ist Terraform nur für ayedo Managed Kubernetes relevant?

Nein. Die DNS-Verwaltung ist von der Compute-Umgebung getrennt und kann auch für eigene oder bei anderen Providern betriebene [Kubernetes]-Cluster eingesetzt werden.

Fazit

DNS mit Terraform zu verwalten, ist vor allem eine Entscheidung für kontrollierbare Betriebsprozesse. Die DNS-API liefert die programmierbare Schnittstelle, Terraform beschreibt den gewünschten Zustand, und Versionskontrolle sowie Reviews machen Änderungen nachvollziehbar. Die ayedo Edge Cloud unterstützt damit eine klare Trennung zwischen zentralem öffentlichem DNS-Einstieg und den dahinterliegenden Compute-Umgebungen. Entscheidend ist, manuelle Ausnahmen bewusst zu behandeln und nicht dauerhaft parallel zur deklarativen Konfiguration zu betreiben.