Zusammenfassung

  • AFRINICs Standarddateien zur Ressourcenvergabe mit den Namen 10., 11. und 12. September 2026 sind vollständig bytegleich. Interne Nummer und Periodenende lauten jeweils 20260910; die erweiterten Dateien zeigen dasselbe Muster.
  • Gleiche Bytes beweisen weder einen Ausfall noch das Ausbleiben neuer Registerereignisse. Ein knapper Veröffentlichungsnachweis könnte eine neue Prüfung ohne Änderungen von wiederverwendeter Ausgabe unterscheiden, ohne Mitgliederakten offenzulegen.

Nicht jeder neue Dateiname steht für einen neuen Datenstand. AFRINICs öffentliches Archiv liefert dafür ein präzises Beispiel. Die am 14. September nach dem Kalender Asia/Shanghai erfassten Standarddateien für den 10., 11. und 12. September umfassen jeweils 491.382 Bytes. Ihr gemeinsamer SHA-256 lautet 54b0cfb6c962fe41815728ef9bff5950cece5fcdd7ab17b94cc3875e68378e07.

Im Kopf steht in allen drei Fällen die interne Nummer 20260910, dazu 9.947 deklarierte Datensätze und der 10. September als Periodenende. Drei Kalendernamen führen zu einer Inhaltsidentität. Diese Feststellung ist belastbar. Die Ursache für die Wiederholung ist es nicht: Die Dateien erklären nicht, welcher neue Prüfungsschritt hinter dem späteren Namen steht.

Die Norm trennt die Zeitangaben

Das bei AFRINIC veröffentlichte RIR Statistics Exchange Format verlangt tägliche Erstellung. Das Datum in delegated-<registry>-yyyymmdd bezeichnet den lokalen Tag der Produktion. Das Feld serial ist dagegen die Nummer der Datei innerhalb der Serie des erzeugenden RIR. Das Periodenende hat ein eigenes Feld. Der Name latest muss bei einer Aktualisierung auf die jüngste Datei zeigen.

Auch die Änderungszeit des Webservers ist keine Ersatzdefinition. Im 2026er Verzeichnis trägt die Datei mit dem Namen 10. September eine Änderungszeit vom 11.; der Name 11. September eine vom 12.; der Name 12. September eine vom 13. Die HTTP-Antworten liefern ebenfalls unterschiedliche Änderungsmetadaten. Diese beschreiben die ausgelieferten Objekte. Sie belegen nicht die tatsächliche Laufzeit des Generators oder den zuletzt geprüften Quellenstand.

Das Stammverzeichnis führt zusätzlich delegated-afrinic-20260913 mit einer Änderungszeit vom 10. September. Der Abruf dieses Objekts liefert dieselben Bytes, ebenso der aktuelle Standardalias. Dateiname, Serverzeit und interne Version schreiten in dieser Stichprobe also nicht gemeinsam fort.

Prüfsummen lösen die andere Frage

Die Gleichheit betrifft nicht bloß eine unveränderte Kopfzeile. Die erweiterten Dateien vom 10., 11. und 12. September sowie ihr aktueller Alias sind jeweils 992.722 Bytes groß. Ihr SHA-256 ist 66f1d06b8f272cbb3f2da3260b73a63cb7b1cd132ad770851dc2e2864ac9eb75; Nummer und Periodenende bleiben 20260910, die deklarierte Zahl beträgt 19.651. Das erweiterte Format fügt Ressourcenstatus und Halterinformationen hinzu, aber keinen Nachweis über diesen Veröffentlichungsvorgang.

Auch die drei MD5-Begleitdateien sind identisch. Die unabhängig berechnete Prüfsumme des Standardinhalts stimmt mit ihrem Wert 568a689f01216f94af0b174514fd3903 überein. Die drei abgetrennten OpenPGP-Signaturobjekte enthalten ebenfalls dieselben Bytes. Eine lokale Signaturprüfung wird hier nicht behauptet.

Die passende Prüfsumme begrenzt die Frage nach Übertragungsfehlern relativ zum veröffentlichten Wert. Selbst eine mathematisch gültige Signatur würde Bytes an einen Schlüssel binden, nicht an eine neue Tagesprüfung. Inhaltsechtheit und Aktualität der Beobachtung sind verschiedene Eigenschaften.

Ein begrenzter Kontrollfall ist die Standarddatei vom 9. September: gleiche Größe und gleiche deklarierte Gesamtzahl, aber eine andere Prüfsumme und eine Nummer vom 9. September. Stabile Summen belegen keine stabilen Zeilen. Vollständige Bytegleichheit belegt dagegen gleichen erfassten Inhalt.

Auch „unverändert“ braucht einen Prüfzeitpunkt

Ein Register kann an einem Tag nichts Neues zu melden haben. Es kann eine geprüfte Ausgabe bewusst erneut bereitstellen. Wiederverwendung ist deshalb nicht von sich aus verdächtig. Für einen Nutzer bleibt jedoch entscheidend, ob die Quellen bis zu einem neuen Stichtag geprüft wurden oder nur das frühere Ergebnis wieder ausgeliefert wurde.

Die öffentlichen Dateien zeigen keine Laufkennung, keinen Quellenstichtag, keine Wiederverwendungsart und keinen ausstehenden Korrekturstatus. Sie unterscheiden einen regulär unveränderten Stand nicht von einem angehaltenen Generator oder einer verzögerten Quelle. Aus dem Vergleich lässt sich weder ein Registerausfall ableiten noch das Fehlen neuer Vergaben bestätigen.

Zwei Erfassungsregeln können die Unklarheit verschärfen. Wer ausschließlich nach URL speichert, zählt möglicherweise drei unabhängige Tagesbeobachtungen eines einzigen Datensatzes. Wer ausschließlich nach interner Nummer dedupliziert, verliert möglicherweise die späteren Veröffentlichungsvorgänge. Datenversion und Veröffentlichung brauchen getrennte Identitäten.

Nutzer können bereits angeforderte URL, Abrufzeit, Antwortmetadaten, Nummer, Periodenende und Digest festhalten. AFRINIC könnte die fehlende Hälfte durch einen kompakten Nachweis ergänzen: Veröffentlichung, tatsächlich geprüfter Quellenstichtag, Validierung und grobe Begründung für gleiche oder erneut ausgegebene Inhalte. Dafür sind weder Mitgliederanträge noch private Supportakten erforderlich.

Beweisgrenze und Quellen

Dies ist ein Vergleich eingefrorener öffentlicher Dateien, kein interner Betriebsbericht. Er belegt Inhaltsgleichheit und beschreibt Norm sowie Servermetadaten. Er belegt keine fehlenden Vergaben, falschen Registerdaten, Ausfälle, manipulierten Datierungen oder Schäden an Routing und RPKI. Eine spätere Korrektur sollte den Vorgänger nicht aus der Geschichte löschen.