Zusammenfassung

  • Eine DNS Catalog Zone führt Mitgliedszonen und Eigenschaften in einer gewöhnlichen DNS-Zone. Der Verbraucher kann daraus automatisch Zonen hinzufügen, entfernen oder umkonfigurieren; die autoritativen Daten der Mitglieder werden getrennt übertragen.
  • Ein korrektes Version-2-Objekt, ein authentisierter Transferpartner, eine lokal zulässige Mitgliedszone, der Besitz des betroffenen Zustands und die tatsächliche Umsetzung im laufenden Server sind voneinander unabhängige Nachweise.
  • Eine belastbare Kontrolle begrenzt zulässige Namen, führt Herkunft pro Katalog und Mitgliedslabel, bewahrt bei kaputten Katalogen den letzten gültigen Stand, stoppt unerwartete Massenänderungen, regelt coo als Zustandsübergabe und prüft die autoritativen Antworten.

Wenn ein Label den Besitzer wechselt

Eine Organisation verlagert den sekundären DNS-Betrieb von einem Anbieter zu einem anderen. Im alten Katalog verweist die Eigenschaft coo auf den neuen. Der neue Katalog nimmt dieselbe Zone mit demselben Mitgliedslabel auf. Die Verbraucher erkennen die abgestimmte Übergabe und führen die Zone unter dem neuen Katalog weiter.

Der Vorgang ist elegant. Er kann eine erneute Übertragung und den Verlust nützlichen Zustands vermeiden. Doch welcher Zustand wurde gerade übergeben? Nur eine Zonenkopie? Auch das Journal? Zeitgeber? DNSSEC-Schlüssel? Produktspezifische Informationen, die der neue Katalogbetreiber nicht erhalten sollte?

RFC 9432 macht das Label zum Schalter. Bleibt es gleich, kann der neue Katalog den zugehörigen Zustand übernehmen. Soll das nicht geschehen, muss der bisherige Eigentümer vor oder gleichzeitig mit coo durch ein neues Label einen Zustandsreset auslösen.

Ein Feld ohne fachliche Bedeutung trägt damit eine sehr konkrete Verwahrungsentscheidung. Wer nur den Zonennamen prüft, übersieht den wichtigsten Teil der Migration.

Eine normale DNS-Zone mit ausführbarer Bedeutung

Der Katalog selbst folgt den Regeln einer DNS-Zone. PTR-Einträge unter zones nennen Mitglieder. Ein eindeutiges Label verankert deren Eigenschaften. Ein TXT-Eintrag version legt für RFC 9432 den Wert 2 fest. AXFR oder IXFR transportieren den Inhalt.

Die Ressourcendaten der Mitgliedszone liegen nicht im Katalog. A-, AAAA-, MX-, NS- und DNSSEC-Daten kommen über den eigenen Transfer des Mitglieds. Der Katalog bewirkt zunächst, dass der Verbraucher eine Zone konfiguriert und einen Primärserver anspricht.

Deshalb gibt es zwei Konvergenzen. Die Konfigurationskonvergenz beantwortet, welche Mitglieder ein Server kennt. Die Datenkonvergenz beantwortet, welche Version dieser Mitglieder er ausliefert. Ein erfolgreicher Katalog-IXFR kann mit einem gescheiterten Mitgliedstransfer enden. Eine entfernte Zone kann an einem anderen Knoten noch laufen. Ein NOTIFY kann vor der Aufnahme des Mitglieds eintreffen.

Der letzte Katalog-Serial ist somit kein Servicebeweis. Die Kette muss über die lokale Entscheidung, die aktive Konfiguration, den Mitgliedstransfer und den Load bis zur von außen beobachteten autoritativen Antwort reichen.

Fünf getrennte Freigaben

Die Strukturfreigabe prüft die gemeinsame Grammatik. Es darf nur einen erwarteten Versionseintrag geben. Ein Mitglieds-PTR-RRset enthält genau ein Ziel. Verschiedene Labels dürfen nicht dasselbe Mitglied duplizieren. Eine ungültig geformte bekannte Eigenschaft macht den Katalog kaputt. Unbekannte Datensätze werden ignoriert.

Die Herkunftsfreigabe prüft den Transfer. TSIG authentisiert DNS-Transaktionen; Zonentransfer über TLS kann den Kanal zusätzlich schützen und vertraulich halten. Das belegt den konfigurierten Gegenpart und die beobachtete Nachricht, nicht die Richtigkeit seines Inventars.

Die Zulassungsfreigabe bleibt beim Verbraucher. RFC 9432 beschreibt, dass die administrative Kontrolle über die ausgelieferten Zonen vollständig zum Katalogproduzenten wandert, und empfiehlt deshalb eine Begrenzung zulässiger Mitglieder, etwa per regulärem Ausdruck oder Abgleich mit einer anderen Datenbank.

Die Zustandsfreigabe fragt, ob genau dieser Katalog die Zone und den zu löschenden Zustand ursprünglich geschaffen hat. Gleicher Name bedeutet nicht automatisch gleiche Herkunft.

Die Laufzeitfreigabe prüft, was die konkrete Softwareversion umgesetzt hat und was DNS-Abfragen zeigen. Ein gespeicherter Konfigurationseintrag ist weder ein erfolgreicher Load noch eine weltweit konsistente Antwort.

Erst die Folge aller fünf Nachweise rechtfertigt die Aussage, eine Änderung sei erfolgreich bereitgestellt.

Kaputt ist eindeutig; leer kann gefährlich korrekt sein

Fehlt die Version, enthält ein PTR-RRset mehrere Ziele, verweisen mehrere Labels auf dasselbe Mitglied oder ist eine bekannte Eigenschaft ungültig, darf der Verbraucher den Katalog nicht verarbeiten. Wird ein zuvor gültiger Katalog kaputt, dürfen bestehende Mitglieder nicht entfernt oder neu konfiguriert werden. Auch nach einem Neustart soll der letzte gültige Zustand weiterlaufen.

Ein leerer Version-2-Katalog verletzt diese Regeln nicht. Vielleicht hat der Inventarleser wegen eines abgelaufenen Zugriffsrechts null Zeilen geliefert. Der Generator baut daraus eine syntaktisch einwandfreie Zone, erhöht den Serial und signiert beziehungsweise authentisiert den Transfer korrekt. Der Fehler liegt vor der Protokollgrenze.

RFC 9432 warnt, dass ein solches Skript Millionen von Mitgliedszonen innerhalb weniger Sekunden von Sekundärservern löschen könnte. Daher braucht der Verbraucher zusätzlich eine semantische Differenzkontrolle: Anzahl und Anteil von Löschungen, betroffene Suffixe und Kundengruppen, Labelwechsel, neue Eigenschaften, Wartungsfenster und Vergleich mit einer unabhängigen Quelle.

Ein unerwartet leerer Katalog gehört in Quarantäne. Ein Parser kann Korrektheit der Form feststellen; er kann keine verlorene Datenbankberechtigung erkennen.

Löschbefugnis braucht eine Herkunftskette

Entfernt ein Katalog ein Mitglied, darf der Verbraucher Zone und zugehörigen Zustand nur löschen, wenn dieselbe Zone ursprünglich aus genau diesem Katalog konfiguriert wurde. Eine statisch oder durch einen anderen Katalog angelegte Zone bleibt außerhalb dieser Befugnis.

Für jedes Mitglied sind daher Ursprungskatalog, Mitgliedslabel, erster akzeptierter Serial, lokales Konfigurationsprofil, erzeugte Speicherbereiche und spätere Eigenschaftsänderungen festzuhalten. Eine flache Liste aktiver Zonen kann die Löschfrage nicht beantworten.

Bei passender Herkunft kann der betroffene Zustand Zonendaten und DNSSEC-Schlüssel umfassen. Der RFC nennt eine vorübergehende Archivierung als mögliche Fehlerhilfe. Dafür müssen Dauer, Verschlüsselung, Wiederherstellungsbefugnis und Abgleich mit dem aktuellen Primärzustand festgelegt sein.

Unbegrenzte Aufbewahrung vergrößert den Geheimnisbestand; sofortiges Löschen macht einen Inventarfehler endgültig. Und ein erneuter Transfer des alten Katalogs ist nicht zwingend eine Wiederherstellung: Nach der Bereinigung kann derselbe PTR lediglich eine neue, leere lokale Instanz erzeugen.

coo ist ein beidseitiges Protokoll, keine Zielbehauptung

Für eine Eigentumsänderung muss der alte Katalog auf den neuen verweisen. Der Verbraucher wartet, bis das Mitglied auch im neuen Katalog erscheint, und prüft vor der Migration erneut, ob der Verweis im alten noch besteht. Das Ziel kann sich die Zone nicht allein zuschreiben.

Teilweise Beobachtung bleibt dennoch möglich. Ein Verbraucher kann die Hinzufügung im neuen Katalog sehen, bevor er die Entfernung im alten verarbeitet hat, und daraus einen Namenskonflikt ableiten. Ein anderer hat die Reihenfolge bereits vollständig gesehen. RFC 9432 lässt einen Teil der Wiederherstellung außerhalb des Standards und nennt als mögliches Mittel eine erzwungene erneute Übertragung.

Operations braucht deshalb Sichtbarkeit pro Verbraucher: Serial beider Kataloge, alter coo-Nachweis, Mitgliedslabel, Konfliktstatus, Zustandsentscheidung und Zeitpunkt der tatsächlichen Umschaltung. Eine globale Anzeige „Migration abgeschlossen“ verschleiert die unterschiedlichen Beobachtungsstände.

Gruppen und private Erweiterungen

group trägt keine vorgegebene Bedeutung. Produzent und Verbraucher vereinbaren, welche Zeichenfolge zu welchem lokalen Konfigurationsprofil gehört. Unverstandene Werte müssen ignoriert werden; bei mehreren Werten entscheidet die Implementierung.

Eigenschaften unter ext sind implementierungsspezifisch und versprechen keine allgemeine Interoperabilität. IANA führt für Version 2 zones, version, coo, group und *.ext. Die Registrierung koordiniert Bezeichner. Sie macht aus einer privaten Eigenschaft keine universelle Anweisung.

Das entspricht Heng Lus Minimum Initial Specification: Eine kleine, deterministische gemeinsame Schicht ermöglicht lokale Prüfung. Spätere Bedeutungen bleiben bei den Teilnehmern. Veröffentlichung allein erzeugt keine Wirklichkeit; erst freiwillige Implementierung und beobachtete Ausführung tun es.

Drei Implementierungen, verschiedene Folgen

BIND dokumentiert das automatische Hinzufügen, Entfernen und Umkonfigurieren, die Schema-Versionen 1 und 2, den Label-basierten Reset sowie coo. Ein Mindestintervall begrenzt die Taktung, nicht den erlaubten Inhalt.

Knot DNS ordnet Gruppen lokalen Profilen zu und beschreibt, dass ein aus dem Katalog entferntes Mitglied sofort einschließlich Zonendatei, Journal, Zeitgebern und DNSSEC-Schlüsseln bereinigt wird; für die Zonendatei gilt die dokumentierte Ausnahme. Eine Katalogaktualisierung kann zudem einen breiteren Reload auslösen.

PowerDNS dokumentiert Version-2-Produzenten und -Verbraucher, coo, mehrere Gruppen sowie einen eindeutigen Wert für den Zustandsreset. Unterstützte Backends und Eigenschaften bilden einen eigenen Umfang.

„RFC-9432-fähig“ ist daher keine ausreichende Risikobeschreibung. Jede Releasekombination muss mit kaputtem und leerem Katalog, Namenskonflikt, unbekannter Gruppe, Löschung, Labelwechsel, unvollständigem coo, Neustart und Wiederherstellung getestet werden. Running-Code Primacy verlangt den Nachweis am laufenden Produkt.

Ein Autoritätsjournal bis zur DNS-Antwort

Für jeden akzeptierten Serial gehören Inhalts-Hash, normalisierte Differenz, authentisierter Gegenpart, Transport, Struktururteil, Zulassungsregel, Herkunft und Label der Mitglieder, Konflikte, Anwendung je Verbraucher, Mitgliedstransfer, Load und externe autoritative Abfragen in denselben Nachweis.

Bei Löschungen kommen Zustandsinventar, Archivkennung, Löschzeit und Wiederherstellungsfrist hinzu. Bei coo werden beide Katalogbeobachtungen, Labelkontinuität oder Reset und die ausdrückliche Verwahrungsentscheidung erfasst. Geheimnisse und vollständige sensible Kataloginhalte bleiben aus gewöhnlichen Logs heraus.

Das Journal muss ohne Vermutung zeigen: was der Produzent veröffentlichte, wer den Transfer authentisierte, was der Verbraucher zuließ, welchen Zustand der Katalog besaß, was die Software ausführte und was Nutzer anschließend auflösen konnten.

Quellen