Zusammenfassung

  • Die DNS-NOTIFY-Antwort bestätigt den Empfang der Benachrichtigung, enthält aber keine nützliche Zoneninformation.
  • SOA-Vergleich, IXFR oder AXFR, Laden der Generation und beobachtete autoritative Antworten bleiben getrennte Nachweise.
  • Ein Zonenveröffentlichungsbeleg muss alle Übergaben erhalten, statt einen Benachrichtigungserfolg zur Serving-Garantie zu machen.

Eine leere Retry Queue ist kein Serving-Beweis

RFC 1996 beschleunigt Änderungen, indem ein Master Secondaries benachrichtigt, statt nur den Refresh-Timer abzuwarten. Trifft die passende Antwort ein, darf der Master diesen Empfänger aus der Wiederholungswarteschlange für das Ereignis entfernen. Genau das ist bewiesen.

Die Antwort meldet weder die lokale SOA-Seriennummer noch den Transferstatus oder die aktive Datengeneration. Laut Spezifikation enthält sie keine nützliche Information. Eine grüne NOTIFY-Anzeige beschreibt deshalb die Zustellung des Auslösers, nicht den Abschluss der Zonenveröffentlichung.

Nach einem gültigen SOA-NOTIFY fragt der Secondary einen bekannten Master nach dessen SOA, vergleicht die Seriennummern und beginnt bei einem Fortschritt IXFR oder AXFR. Die Bestätigung liegt vor diesen Schritten.

Transfer und Aktivierung getrennt halten

Eine optionale Answer Section im NOTIFY ist nur ein unsicherer Hinweis und darf lokale Zonendaten nicht aktualisieren. RFC 1982 definiert Seriennummernarithmetik; bei genau halbem Abstand ist der Vergleich nicht definiert. Ein belastbarer Nachweis speichert beide Werte und das tatsächliche Vergleichsergebnis.

IXFR überträgt Änderungen, AXFR kann die vollständige Zone übertragen. RFC 5936 ordnet AXFR den Kohärenzmechanismen für autoritative Server zu. Ein erfolgreicher Transfer beweist dennoch nicht den Reload jedes Prozesses oder die Konvergenz aller Anycast-Standorte.

Abschließend müssen direkte autoritative Abfragen die erwartete SOA und einen tatsächlich geänderten RRset zeigen. Rekursive Caches und ihre TTL sind davon getrennt.

Quellen