Zusammenfassung

  • Das ursprüngliche DNS ließ Secondaries in REFRESH-Abständen die SOA-Serie des Primaries abfragen. Das sparte Last, machte aber vorübergehend unterschiedliche Antworten autoritativer Server zum vorgesehenen Betriebszustand.
  • DNS NOTIFY spielte keine neue Zone ein. Es veranlasste den Secondary zur Serienprüfung; IXFR konnte danach die geordnete Folge aus Löschungen und Ergänzungen seit dessen vorhandener Version liefern.
  • Der schnellere Weg blieb durch modulare Serienarithmetik, AXFR-Rückfall, stabile Speicherung, vollständige Verarbeitung, atomare Aktivierung und optionales TSIG begrenzt. Das Signal beschleunigte die Prüfung, nicht den Gehorsam.

Wenn Autorität zwei Gegenwarten beschrieb

Mehrere autoritative Server schützen eine Zone davor, von einer Maschine oder Leitung abhängig zu sein. Sobald sich die Zone ändert, entsteht jedoch eine Replikationsschuld: Bis alle Kopien nachgezogen haben, können gleichberechtigte Autoritäten verschiedene Versionen der Gegenwart ausliefern.

RFC 1034 ordnete Änderungen einem Primary zu. Secondaries fragten regelmäßig den SOA-Datensatz ab, verglichen SERIAL und übertrugen die Zone, wenn der Primary eine neuere Version besaß. REFRESH bestimmte den normalen Prüfzeitpunkt, RETRY den erneuten Versuch nach Fehlern und EXPIRE die Grenze, nach der eine nicht erneuerbare Kopie nicht länger autoritativ antworten durfte. RFC 1035 definierte die 32-Bit-Felder und AXFR als vollständige Zonenübertragung.

Das Verfahren war sparsam. Eine unveränderte Zone verursachte nur kleine SOA-Anfragen. Der Secondary behielt Initiative und Ablaufgrenze; der Primary musste keine dauerhafte Verbindung zu jeder Replik verwalten. Doch die Inkohärenz bekam eine konfigurierbare Dauer. Kurze Intervalle erzeugten auch in Ruhe Last, lange Intervalle ließen alte Autorität länger leben.

Diese Verzögerung ist nicht mit Resolver-Caches gleichzusetzen. Ein rekursiver Resolver kann nach vollständiger autoritativer Konvergenz bis zum TTL-Ende alte RRs behalten. Vor der Konvergenz können zwei leere Resolver unterschiedliche Antworten erhalten, weil sie verschiedene autoritative Server treffen. NOTIFY und IXFR adressieren diese zweite, vorgelagerte Divergenz.

Häufig fragen oder spät erfahren

Mit wachsenden Zonen wurden zwei Missverhältnisse sichtbar. Eine kleine Änderung früh zu entdecken erforderte häufiges Polling, selbst wenn nichts geschah. Sie zu übernehmen konnte anschließend eine komplette AXFR-Kopie verlangen. Entdeckungs- und Transportaufwand folgten nicht der tatsächlichen Änderung.

RFC 1996 benannte den Tausch: Lange Aktualisierungszeiten reduzierten Masterlast, verlängerten aber die Inkohärenz. DNS NOTIFY stellte dem Polling einen Interrupt zur Seite. Nach dem Laden einer neuen Version konnte ein Master ausgewählte Secondaries darauf hinweisen, dass eine Prüfung sinnvoll war.

Die Empfänger installierten nicht den Inhalt der Nachricht. Sie fragten die SOA bei einem konfigurierten Master ab, verglichen die Serie und begannen nur bei Bedarf eine Übertragung. Optionale Daten im NOTIFY waren ein ungesicherter Hinweis. Der Sender durfte die Prüfung vorziehen, nicht den fremden Zustand direkt ändern.

Die Standardmenge der Benachrichtigten entsprach den NS-Servern ohne den im SOA-MNAME genannten Master. Betreiber konnten sie überschreiben oder Stealth-Secondaries hinzufügen. Transferbeziehungen mussten einen schleifenfreien Abhängigkeitsgraphen bilden. Ein aktualisierter Secondary konnte wiederum Master für nachgelagerte Server sein.

Ein Klopfen ist kein Paket im Haus

NOTIFY arbeitete nach bestem Bemühen. Über UDP konnte der Master wiederholen, bis eine Antwort kam oder die Versuchsgrenze erreicht war. Ein Secondary konnte dieselbe Änderung von mehreren Upstreams hören und musste Duplikate unterdrücken, solange eine Aktualisierung lief. Mehrere Signale sollten nicht mehrere gleichzeitige Transfers auslösen.

Die Antwort bestätigte Empfang, nicht Konvergenz. Gefälschte Quellen konnten unnötige SOA-Abfragen provozieren; ältere Server konnten NOTIMP melden. Ging die Nachricht verloren, blieb REFRESH der Wiederherstellungspfad. Deshalb ist „DNS-Push“ als Kurzform ungenau: Gepusht wurde Dringlichkeit, nicht selbstvollziehende Zonendaten.

Die Zahl, die nach Null weiterläuft

Versionsprüfung benötigt eine Ordnung. Eine 32-Bit-Serie springt nach ihrem Höchstwert zu Null; normaler Ganzzahlvergleich würde die Zukunft für älter halten. RFC 1982 definierte dafür einen endlichen Sequenzraum.

Addition ist modular und begrenzt. Nahe Werte lassen sich über den Nullpunkt hinweg ordnen; bei genau einem halben Umlauf Abstand ist keine Ordnung definiert. Innerhalb einer EXPIRE-Periode darf die Serie nicht um mehr als 2^31−1 voranschreiten, sonst kann ein alter Secondary scheinbar vorausliegen.

Eine Serie ist weder Datum noch Unterschrift. Sie verrät nicht, wer eine Änderung billigte oder ob deren Inhalt richtig ist. Sie liefert eine relative Position in einer zulässigen Folge. Gerade diese enge Aussage macht sie für Replikation brauchbar und verbietet ihre Umdeutung zum Eigentums- oder Identitätsnachweis.

Die Bearbeitung statt des Archivs senden

NOTIFY verringerte die Entdeckungszeit. RFC 1995 führte IXFR ein, um den Nachzug zu verkleinern. Der Client sendet die SOA-Serie seiner vorhandenen Kopie. Kennt der Server diesen Stand und besitzt die Historie, antwortet er mit geordneten Lösch- und Ergänzungsfolgen bis zur aktuellen Version.

Eine RR-Änderung erscheint als Entfernung der alten und Aufnahme der neuen Form. SOA-Datensätze begrenzen jede Transition. Das Ergebnis ist kein kontextfreier Patch, sondern ein Weg von X nach Y. Erst nach Verarbeitung der gesamten Folge ersetzt der Client seine alte Zone.

Der Server musste die Geschichte nicht ewig bewahren. Er konnte alte Differenzen verwerfen, besonders wenn IXFR größer als AXFR würde, und Informationen jenseits von EXPIRE löschen. Er durfte Zwischenversionen verdichten. War der Ausgangsstand unbekannt, lieferte er die ganze Zone.

Dieser Rückfall war eine Sicherheitsbedingung. Differenzen setzen gemeinsamen Ausgangspunkt und erhaltenen Pfad voraus. AXFR stellt einen vollständigen gemeinsamen Zustand her, wenn das Journal fehlt, der Ausfall zu lange dauerte oder die Änderung zu groß wurde. Optimierung blieb optional; Wiederherstellbarkeit nicht.

Erst dauerhaft machen, dann verteilen

RFC 1995 verlangte stabile Speicherung, bevor eine neue Version über IXFR oder AXFR verteilt wird. Sonst könnte ein Master Daten ausgeben, abstürzen und ohne die von Secondaries bereits angenommene Generation zurückkehren. Schnelligkeit würde dauerhafte Inkonsistenz erzeugen.

RFC 5936 präzisierte die Empfängerseite. Ein AXFR-Client nimmt die Zone getrennt entgegen, prüft sie und schaltet sie atomar frei. Scheitert die Übertragung, bleibt die vorherige gültige Version sichtbar. Bei IXFR gilt dasselbe Prinzip: Eine halbe Differenzkette wird keine halbe öffentliche Autorität.

Der schnelle Pfad besteht folglich aus getrennten Toren: Benachrichtigung, Serienbeweis, Kandidatentransfer und Aktivierung nach vollständiger Prüfung. Die zuerst eingetroffene Nachricht darf keines überspringen.

Den Transport authentisieren, nicht die Wahrheit

Zonentransfers können Daten offenlegen und autoritative Antworten verändern. RFC 5936 empfiehlt Zugriffskontrolle und Integritätsschutz. RFC 8945 definiert TSIG mit gemeinsamen Geheimnissen und Nachrichtenauthentisierung.

Bei mehrteiligen TCP-Transfers können MACs verkettet und Manipulationen erkannt werden. Der Empfänger weiß, dass die Gegenseite das vereinbarte Geheimnis besitzt. TSIG verschlüsselt den Kanal jedoch nicht, verteilt keine Schlüssel und wird bei vielen Beziehungen schwer zu verwalten.

Vor allem authentisiert TSIG die Übertragung, nicht die Wahrheit der Quelldaten. Ein kompromittierter oder irrender Master kann eine falsche Zone kryptografisch korrekt übertragen. Ein gültiger MAC beweist weder rechtliches Eigentum am Namen noch institutionelle Zustimmung oder sachliche Richtigkeit. Die Sicherheitsgrenze ist punktuell und sollte nicht in ein allgemeines Mandat verwandelt werden.

Eine stille Teilung von Macht

NOTIFY und IXFR wirken wie Leistungsoptimierungen, beantworten aber eine Frage verteilter Autorität: Wie kann ein Betreiber einen anderen zu schneller Änderung bewegen, ohne dessen Ausführung zu kontrollieren? Die Standards zerlegten den Vorgang in kleine Aussagen: Etwas änderte sich. Meine Serie ist Y. Von deinem X führt diese Differenz nach Y. Ohne gemeinsame Historie gibt es eine vollständige Kopie. Diese Transaktion stammt von einem Besitzer des vereinbarten Geheimnisses.

Keine Aussage genügte allein. Der Secondary prüfte Ausgangspunkt, Quelle, Vollständigkeit und Aktivierung. Darum konnten veraltete autoritative Daten früher verschwinden, ohne dass das schnellste Paket automatisch zur Wahrheit wurde.

Auch Fehler konvergieren schneller. Eine falsche Änderung kann alle Standorte vor der ersten Beschwerde erreichen; ein kurzes Journal kann nach langem Ausfall viele AXFRs auslösen; eine misshandelte Serie kann Repliken einfrieren. Beschleunigung ersetzt keine Betriebsführung, sondern verlagert Prüfung und Reversibilität vor die Verteilung.

Die Zone lernte anzuklopfen. Der Secondary wachte früher auf. Für das Öffnen, Prüfen und das anschließend autoritativ Gesagte blieb er selbst verantwortlich.

Quellen und Beweisgrenzen

RFC 1034 und RFC 1035 begründen Polling, SOA-Zeiten und AXFR. RFC 1982 definiert Serienarithmetik. RFC 1995 definiert IXFR und vollständigen Rückfall. RFC 1996 definiert NOTIFY und den konfigurierten Graphen. RFC 5936 verlangt vollständige atomare Aktivierung. RFC 8945 beschreibt TSIG und seine Grenzen.

Die Dokumente belegen weder einen weltweiten Einführungstermin noch universelle Parameter oder gemessene globale Konvergenzzeiten. Belegt ist die Architektur: Signal, Versionsnachweis, Transfer und lokale Ausführung blieben getrennt.