Zusammenfassung

  • Eine Mitgliedschaft nach RFC 9432 verändert die Consumer-Konfiguration und ist deshalb ein Betriebsbefehl, kein passives Inventar.
  • Authentisierung muss durch vertrauliche Übertragung, Zulassungsgrenzen und ausdrückliche Regeln für die Zustandsmigration ergänzt werden.

Die Liste verändert den Dienst

Ein gewöhnlicher Zonentransfer synchronisiert den Inhalt einer DNS-Zone, nicht die Liste der Zonen, die ein Secondary bedienen soll. RFC 9432 stellt diese Liste als reguläre DNS-Zone dar. Der Produzent veröffentlicht Mitglieder als PTR-Einträge und Eigenschaften; der Consumer überträgt den Katalog und konfiguriert sich daraus.

Das reduziert wiederholte Arbeit und implementierungsspezifische Fehler. Zugleich wandert Macht. Laut Spezifikation geht die administrative Kontrolle darüber, welche Zonen bedient werden, vom Consumer-Betreiber vollständig auf den Produzenten über. Eine Aktualisierung kann Dienste auf vielen Servern hinzufügen, entfernen oder verändern.

Ein beschädigter Katalog darf nicht verarbeitet werden. Fehlende oder unbekannte Pflichtversionen, doppelte Mitglieder und ungültige bekannte Eigenschaften nehmen ihm seine Befehlswirkung. Wird ein zuvor gültiger Katalog beschädigt, dürfen bestehende Mitglieder weder entfernt noch neu konfiguriert werden; der letzte gültige Zustand bleibt bestehen.

Ein gültiger, aber leerer Katalog ist dagegen nicht beschädigt. Er kann die Entfernung aller durch ihn eingerichteten Zonen anweisen. Vor der Veröffentlichung muss die erzeugte Population daher gegen ein genehmigtes Inventar geprüft werden. DNS-Syntax allein genügt nicht.

Eigentumswechsel kann Zustand übertragen

Die Eigenschaft coo koordiniert den Wechsel zwischen Katalogen. Der Consumer wartet, bis der Zielkatalog das Mitglied enthält, und prüft anschließend die Anweisung des alten Katalogs erneut. Bleibt das Member-Label gleich, kann der neue Eigentümer den zugehörigen Zustand übernehmen; ein neues Label setzt ihn zurück.

Damit stehen Zonendaten, DNSSEC-Schlüssel und Betriebseigenschaften an einer Autoritätsgrenze. Der Nachweis sollte beide Kataloge, Label, Genehmiger, gewünschte Zustandsbehandlung und die sichtbare Übereinstimmung enthalten.

Ein sicherer Kanal beweist keine richtige Absicht

RFC 9432 empfiehlt die Authentisierung von Transfers und Updates. TSIG aus RFC 8945 authentisiert DNS-Nachrichten. RFC 9103 ermöglicht Zonentransfer über TLS mit Vertraulichkeit und TLS-Authentisierung. Gemeinsame TSIG-Geheimnisse gehören nicht in den Katalog.

Diese Maßnahmen schützen Kanal und Absenderbeziehung, nicht die Auswahl der Mitglieder. Consumer sollten zulässige Zonen über ein externes Inventar oder eine gleichwertige Regel begrenzen. Vertraulichkeit ist nötig, weil der Katalog bediente Zonen und Verwaltungseigenschaften offenlegt.

Die Quellen belegen weder einheitliche Verbreitung noch Vorfälle bestimmter Betreiber oder messbare Wirkungen. Betreiber und Kunden profitieren von konsistenter Provisionierung; die Kosten liegen in konzentrierter Autorität und größerem Schadensradius. Manuelle Konfiguration ist langsamer und uneinheitlicher, erschwert aber die sofortige Ausbreitung eines einzelnen Fehlers.

Quellen