Zusammenfassung

  • Der am 12. September gesicherte Verzeichnisstand enthielt 150 Reverse-DNS-Datendateien in 75 Namenspaaren, 150 getrennte Signaturen und einen öffentlichen Schlüssel.
  • Das geprüfte Paar war bytegleich; auch der veröffentlichte MD5-Wert passte. Solche Kontrollen belegen eine einzelne Datei, nicht die Vollständigkeit einer Generation.
  • Das fehlende Manifest beweist weder eine Lücke noch eine ungültige Signatur oder DNS-Störung. Es lässt lediglich den Abschluss des gesamten Veröffentlichungsbatches unsigniert.

Wer genau eine bekannte Datei abholen will, bekommt von LACNIC einen brauchbaren Prüfpfad. Neben 002-LACNIC liegen eine gleichnamige .asc-Signatur und eine .md5-Zeile. Im selben Verzeichnis steht PUBLIC_KEY. Die Bausteine für eine dateibezogene Kontrolle sind öffentlich auffindbar.

Ein Spiegelbetreiber stellt jedoch eine andere Frage. Er will nicht nur wissen, ob Datei A echt ist, sondern ob A bis Z gemeinsam den von LACNIC abgeschlossenen Stand bilden.

Die Aufnahme um 15:21 UTC zeigte 150 Datennamen. 75 davon folgten dem dreistelligen Muster 002-LACNIC; 75 nutzten die entsprechende DNS-Form 2.in-addr.arpa-LACNIC. Jedes dreistellige Element hatte sein numerisches Gegenstück. Hinzu kamen 150 .asc- und 151 .md5-Einträge sowie der öffentliche Schlüssel. Die zusätzliche MD5-Zeile war der im Index mit Größe null angezeigte Platzhalter *-LACNIC.md5.

Kein Dateiname verwies auf ein README, Manifest, SHA-256-Verzeichnis oder Release-Kennzeichen. Das ist eine Beobachtung am öffentlichen HTTP-Stand, keine Aussage über interne Protokolle des Generators.

Ein Paar, zwei Schreibzeitpunkte

Die Dateien 002-LACNIC und 2.in-addr.arpa-LACNIC umfassten jeweils 2.222 Bytes und hatten denselben SHA-256-Wert. Der publizierte MD5-Wert der ersten Datei stimmte mit den empfangenen Bytes überein. Ihre HTTP-Zeitstempel lagen eine Sekunde auseinander.

Aus dieser Sekunde folgt kein Fehler. Zwei Kompatibilitätsnamen können nacheinander geschrieben werden. Bewiesen ist nur, dass dieses Paar zum Beobachtungszeitpunkt identisch war. Die übrigen 74 Paare wurden nicht byteweise verglichen, und die Quellen versprechen keine dauerhafte Gleichheit.

Die Stichprobe enthält $ORIGIN . und NS-Delegationszeilen. Sie ist weder eine Live-Abfrage autoritativer Server noch ein Nachweis, dass alle Server denselben Stand geladen haben. Download, autoritative Aktivierung und die vom Resolver beobachtete Antwort sind getrennte Evidenzstufen.

Einzelne Provenienz ist keine Mengenangabe

RFC 9580 beschreibt abgetrennte OpenPGP-Signaturen über externe Daten. Akzeptiert ein Prüfer den Schlüssel für diesen Zweck und führt die Prüfung aus, kann er eine konkrete Datei mit der Signatur verbinden.

In der Untersuchungsumgebung fehlte ein OpenPGP-Prüfprogramm. Deshalb trifft dieser Artikel weder eine positive noch eine negative Aussage über die Gültigkeit der Stichprobensignatur oder das Vertrauen in den benachbarten Schlüssel. Fest steht nur: LACNIC stellt Material für eine Dateiprüfung bereit. Das ist eine bestehende Stärke.

Auch eine erfolgreiche Signaturprüfung von 002-LACNIC zählt nicht die anderen 149 erwarteten Namen auf. Der HTML-Index zeigt, was der Server in einem Moment auslieferte. Er sagt nicht signiert, ob gerade aktualisiert wurde oder ob die Generation geschlossen war. Last-Modified ist Transportmetadatum, keine Batch-Identität.

MD5 hat eine noch engere Aufgabe. RFC 6151 verwirft MD5 dort, wo Kollisionsresistenz erforderlich ist, lässt aber begrenzte Fehlererkennung zu. Die Übereinstimmung der Probe hilft gegen Übertragungsfehler. Sie authentifiziert weder den Herausgeber noch die Mitgliedschaft im Gesamtbestand.

Warum die Einzeldatei trotzdem sinnvoll ist

Möglicherweise soll dieses Verzeichnis gar keinen atomaren Snapshot darstellen. Ein Nutzer kennt seinen Dateinamen, lädt nur diesen Teil und hält ihn im Cache. Unabhängige Dateien sparen Übertragung und erlauben gezielte Aktualisierung. Für diesen Vertrag wäre ein zwingendes Gesamtpaket unnötig.

Die Kritik setzt erst bei der Vollspiegelung an. Ein Automat kann lauter authentische Einzeldateien sammeln und trotzdem zwei Generationen vermischen. Sämtliche Datei-Prüfungen wären erfolgreich, während die Aussage „vollständiger Stand“ unbelegt bliebe.

Ein kleines signiertes Manifest würde genügen. Es nennt Version, Batch-ID, Erzeugungs- und Abschlusszeit sowie die geordnete Soll-Liste. Pro Eintrag folgen Paar-ID, Namensrolle, Bytezahl, SHA-256 und Signaturdatei. Der akzeptierte Schlüsselfingerabdruck und der Vorgängerbatch schließen die Kette.

Korrekturen sollten einen neuen Manifeststand erzeugen und den alten als ersetzt markieren. Beabsichtigte Unterschiede zwischen zwei Namen könnten über die Rolle erklärt werden. Ein Feld „Veröffentlichung abgeschlossen“ würde Zwischenstand und fertige Generation auseinanderhalten.

Das Manifest bestätigt nicht den laufenden DNS-Dienst. Es sagt nichts über die Richtigkeit einer Delegation oder Resolverantwort. Es dokumentiert nur, welche Download-Dateien LACNIC zu welchem Zeitpunkt als zusammengehörig freigegeben hat.

Die einzelnen Siegel sind vorhanden. Für ein reproduzierbares Werk fehlt das signierte Inhaltsverzeichnis.

Quellen