Zusammenfassung

  • Eine Katalogzone ist kein passives Inventar: Eine gültige Generation kann Mitgliedszonen auf vielen autoritativen Servern anlegen, entfernen oder mit neuem Zustand aufbauen.
  • TSIG und XFR über TLS sichern Herkunft und Transport, nicht die Geschäftsabsicht. Sichere Annahme verbindet Quellinventar, lokale Zulassung, wiederherstellbaren Zustand und echte DNS-Antworten.

Ein Generator liefert eine Zone mit gültiger SOA, vorgeschriebenem NS, genau einem Versionswert 2 und neuer Seriennummer. Der Transfer ist authentifiziert. Es gibt weder doppelte PTRs noch ungültige Eigenschaften — und kein einziges Mitglied.

Nach RFC 9432 ist das kein kaputter Katalog, sondern ein gültiger leerer Bestand. Mitglieder, die ursprünglich aus genau diesem Katalog konfiguriert wurden, sind zu entfernen. Der RFC warnt ausdrücklich, ein fehlerhaftes Skript könne so innerhalb von Sekunden Millionen Zonen auf Sekundärservern löschen. Das ist ein Standardszenario, kein Bericht über einen benannten Vorfall.

Alle Protokollprüfungen können bestanden sein, obwohl die ausgedrückte Entscheidung falsch ist.

Oberhalb des Zonentransfers

AXFR und IXFR synchronisieren Inhalte einer bereits eingerichteten Zone. Sie verteilen nicht die Liste der Zonen, die ein Server überhaupt bedienen soll. RFC 9432 codiert diese Liste als besondere reguläre DNS-Zone. PTR-Daten unter eindeutigen Labels in zones.$CATZ nennen Mitglieder; der Verbraucher setzt Änderungen automatisch in Konfiguration um.

Die Mitgliedszone bestimmt also, was geantwortet wird. Der Katalog bestimmt zuerst, ob dieser Server dafür autoritativ werden soll. Der RFC beschreibt den Machtwechsel offen: Die administrative Kontrolle über bediente Zonen geht an den Eigentümer des Kataloginhalts. Zugleich soll der Verbraucher den zulässigen Namensraum lokal begrenzen, etwa durch Muster oder eine unabhängige Datenbank.

Kaputt, authentisch und zulässig

Eine fehlende oder nicht unterstützte Version, doppelte Mitglieder oder formal ungültige bekannte Eigenschaften machen den Katalog kaputt. Dann wird die neue Generation nicht verarbeitet. Zuvor eingerichtete Mitglieder bleiben erhalten; auch Ablauf bedeutet nicht Massenlöschung.

Ein formal leerer Katalog ist dagegen eindeutig. Ebenso kann ein korrekt geschriebener Name außerhalb des Kundenvertrags liegen. Deshalb sind drei Urteile nötig: Schema, Kanalidentität und lokale Zulässigkeit der semantischen Änderung. Ein grüner TSIG-Befund kann die dritte Entscheidung nicht treffen.

Das Label als Griff am Zustand

Das eindeutige Mitgliedslabel besitzt keine geschäftliche Bedeutung, doch seine Änderung wird als Entfernen und Neuanlegen behandelt. Zonendaten, DNSSEC-Schlüssel, Journale und Zeitgeber können dadurch verloren gehen.

coo koordiniert den Wechsel vom alten in einen neuen Katalog. Der Verbraucher wartet auf das Mitglied im Ziel und prüft erneut das Übergabesignal im Ursprung. Gleiches Label kann Zustandsübernahme erlauben; neues Label erzwingt Rücksetzung. Ohne einheitliche coo-Unterstützung kann die Hinzufügung vor der Entfernung eintreffen, als Namenskollision scheitern und eine erneute Übertragung erfordern.

Gleiche Bytes, andere Wirkung

group hat nur die zwischen Produzent und Verbraucher vereinbarte Bedeutung. Unbekannte Werte werden ignoriert; mehrere Werte können ganz, teilweise oder gar nicht wirken. *.ext verspricht keine Interoperabilität.

BIND dokumentiert Verarbeitung pro View und ein Mindestintervall. PowerDNS nennt Backend-Anforderungen und Grenzen bei Gruppen und Erweiterungen. Knot DNS beschreibt externe Validierung, Vorlagen, sofortiges Bereinigen entfernter Mitglieder und Migrationsgrenzen seiner aktuellen Implementierung. Daraus folgt: Ein gleicher Katalog-Hash beweist gleichen Input, nicht gleiche Ausführung. Version, View, Vorlage, Persistenz, Löschregeln und wirksamer Zonenbestand gehören in den Nachweis.

Kryptografie prüft nicht das Quellinventar

TSIG authentifiziert DNS-Transaktionen und schützt ihre Integrität. XFR über TLS kann Vertraulichkeit und Endpunktauthentisierung hinzufügen. Beides ist nötig, weil der Katalog Kunden- und Konfigurationsdaten offenbaren kann.

Doch kein Verfahren erkennt, ob eine Datenbankabfrage wegen eines Fehlers null Zeilen lieferte oder eine Kündigungsliste alle Kunden auswählte. Die Beweiskette beginnt vor DNS: freigegebenes Inventar, erwartete Anzahl, Verantwortlicher, Generatorversion sowie Input- und Output-Hash. Danach folgen Seriennummer, semantischer Diff, Labels, Eigenschaften, Transferidentität und Verbraucherurteil. Am Ende stehen tatsächlich konfigurierte Zonen, Mitgliedstransfers, SOA, Schlüsselzustand und direkte Antworten aus jedem relevanten Standort.

Die NS-Delegation im Elternbereich bleibt getrennt. Entfernt ein Sekundärserver die Zone, kann der Parent Anfragen weiterhin dorthin senden. Erfolgreiche Katalogverarbeitung ist daher noch kein Dienstnachweis.

Quellen