Zusammenfassung

  • Im gesicherten Snapshot für den 8. September von 14:00 bis 15:00 UTC weist WHOIS 3.192.583 total_queries aus; die sieben sichtbaren Typen summieren sich auf 3.183.463. Die Lücke beträgt 9.120, während die RDAP-Zahlen derselben Datei exakt aufgehen.
  • Die Prüfung aller 1.691 Archivstunden zeigt: In jeder der 1.690 Stunden mit WHOIS-Verkehr unterscheiden sich Gesamt- und Typensumme. In 1.011 Dateien ist die Gesamtsumme größer, in 679 die Typensumme. Eine fehlende positive Restkategorie kann beide Richtungen nicht erklären.
  • Eine für APNIC 62 veröffentlichte Präsentation führt prop-167 als noch in Umsetzung und nennt Datenqualitätsprobleme, die gelöst würden. Sie ordnet diese Aussage nicht der hier gemessenen Differenz zu. Nötig ist ein stündlicher Überleitungsnachweis mit Zählstufen, Ausschlüssen, Prüfung und Korrekturhistorie.

Eine öffentliche Statistik gewinnt ihren Wert nicht dadurch, dass eine Zahl groß und präzise aussieht. Sie wird belastbar, wenn sich ihre Bestandteile wieder zu ihr zusammensetzen lassen. APNIC hat mit prop-167 einen nützlichen Schritt gemacht: stündliche WHOIS- und RDAP-Nutzungsdaten sind frei abrufbar, historisch abgelegt und mit Prüfsummen versehen. Die Dateien zeigen Dienste, Abfragetypen, Herkunfts-ASNs und die Zahl unterschiedlicher Quelladressen, ohne die Adressen oder abgefragten Ressourcen offenzulegen.

Gerade diese Offenheit macht eine einfache Rechnung möglich. Der zum Redaktionsschluss gesicherte aktuelle Snapshot deckt am 8. September 2026 die Stunde von 14:00 bis 15:00 UTC ab. Im WHOIS-Block steht total_queries mit 3.192.583. Die Verteilung weist 1.670.618 inetnum, 1.284.709 route, 93.537 aut-num, 88.530 domain, 31.500 organisation, 13.888 as-set und 721 inet6num aus. Addiert ergeben diese Werte 3.183.463.

Zwischen beiden Darstellungen liegen 9.120 Abfragen oder 0,2857% der ausgewiesenen Gesamtsumme. Die veröffentlichte MD5-Prüfsumme stimmt mit der heruntergeladenen JSON-Datei überein. Ein Übertragungsfehler ist damit nicht belegt. Noch wichtiger ist der interne Vergleich: Im RDAP-Block derselben Datei ergeben die fünf Typen genau 588.346, also exakt total_queries.

Eine kleine Abweichung in einer Stunde könnte aus einem kurzen Abschlussversatz entstehen. Das vollständige Archiv zeigt jedoch ein dauerhaftes Vertragsproblem.

Eine Vollprüfung statt einer auffälligen Stichprobe

Die Monatsverzeichnisse beginnen mit der Stunde ab 03:00 UTC am 30. Juni, dem Datum, das die prop-167-Seite als Abschluss der Umsetzung ausweist. Geprüft wurden alle Dateien bis zur Archivstunde, die am 8. September um 14:00 UTC endet. Für diesen Zeitraum waren 1.691 Intervalle zu erwarten; 1.691 Dateien waren vorhanden. Die Dateinamen verlaufen lückenlos. Jedes gzip ließ sich öffnen, jedes JSON lesen, und jeder interne halboffene Zeitraum passte zum Dateinamen. Doppelte dekomprimierte Inhalte gab es nicht.

Der Rechentest war für jede Stunde gleich: alle Werte aus query_type_distribution addieren und mit total_queries vergleichen. Bei jeder sichtbaren ASN-Zeile wurde außerdem die Summe aus query_count_by_type gegen query_count gestellt.

RDAP bildet die Kontrolle innerhalb desselben Bestands. Alle 1.691 Dienstsummen stimmen mit ihren Typen überein. Keine sichtbare ASN-Zeile weist eine interne Differenz auf. Das Dateiformat kann also eine nachvollziehbare Zerlegung liefern.

WHOIS stimmt genau einmal. In der Stunde vom 27. August 09:00 bis 10:00 UTC enthält der WHOIS-Block null Abfragen, null ASNs, eine leere Verteilung und keine Zeilen. Damit hat jede der 1.690 Archivstunden mit WHOIS-Verkehr zwei verschiedene Dienstsummen. In all diesen Stunden gibt es zudem mindestens eine ASN-Zeile, deren Zähler nicht durch ihre Typen rekonstruiert wird. Über den Zeitraum betrifft das 347.490 angezeigte Zeilen.

Die erste Archivstunde trägt das Muster bereits in sich: 4.774.145 Gesamtanfragen stehen 4.801.599 Typenzählern gegenüber. Die Typensumme ist um 27.454 größer. In der letzten geprüften Archivstunde meldet WHOIS 2.989.539 insgesamt und 2.987.334 nach Typen. Diesmal ist die Gesamtsumme um 2.205 größer.

Die wechselnde Richtung ist entscheidend. In 1.011 Dateien liegt total_queries über der Typensumme. Dafür wäre eine denkbare Erklärung, dass der Dienst Anfragen am Eingang zählt, die später keinem veröffentlichten Objekttyp zugeordnet werden können. Eine Restkategorie könnte solche Stunden schließen.

In 679 Dateien übersteigt dagegen die Typensumme das Total. Am 14. Juli von 05:00 bis 06:00 UTC stehen 3.288.941 Gesamtanfragen einer Typensumme von 3.652.538 gegenüber. Die Typen liegen um 363.597 oder 11,0551% höher. Eine nichtnegative Restkategorie kann hier nichts abziehen. Die größte positive Differenz tritt am 20. August von 03:00 bis 04:00 auf: 80.961 oder 2,3823%.

Auch der Saldo aller positiven und negativen Abweichungen wäre keine Zahl „fehlerhafter Anfragen“. Vorzeichen gegeneinander aufzurechnen schafft keine definierte Messgröße. Belegt ist nur, dass eine veröffentlichte Gleichung zwischen den Feldern fehlt.

Zwei ehrliche Zähler können verschiedene Fragen beantworten

Die stärkste Gegenposition ist technisch vernünftig. Ein Zähler am Rand des WHOIS-Dienstes kann jeden angenommenen Befehl erfassen. Ein späterer Parser kann Objekttypen zählen. Eine Anfrage könnte mehr als einen Typ inkrementieren. Ungültige Syntax, interne Wiederholungen, verspätete Ereignisse, verschiedene Abschlusszeitpunkte oder fehlgeschlagene ASN-Anreicherung können die Grundgesamtheiten trennen.

Keine dieser Varianten wäre automatisch ein Fehler. Der öffentliche Mangel besteht darin, dass das README keine davon beschreibt. Es erklärt, jeder Dienstblock enthalte Zeitbereich, Gesamtzahl, ASN-Zahl, Typenverteilung und ASN-Statistiken. Es definiert die UTC-Stunde und das Dateiformat. Nicht definiert sind Messpunkt, Mehrfachklassifikation, Ausschlüsse, Wiederholungsbehandlung, Spätmeldungen oder Abschlusszeit. Ebenso fehlen eine unklassifizierte Kategorie, ein Validierungsstatus und ein Verweis auf korrigierte Versionen.

Deshalb lässt sich nicht entscheiden, ob 3.192.583 oder 3.183.463 die „richtige“ Zahl ist. Vielleicht sind beide für unterschiedliche Fragen korrekt: angenommene Befehle am Rand und erzeugte Klassifikationsinkremente dahinter. Dann müssen die Namen diese Ebenen offenlegen, statt eine Zahl als Gesamtmenge und die andere als deren scheinbare Zerlegung zu präsentieren.

Eine Prüfsumme beantwortet das nicht. Sie bestätigt, dass Leser und APNIC dieselben Bytes besitzen. Sie bestätigt weder eine gemeinsame Einheit noch denselben Zeitpunkt oder dieselbe Population der Felder. Datei-Integrität und metrische Kohärenz sind getrennte Eigenschaften.

Eine zweite stille Grenze betrifft asns. Viele Stunden weisen mehrere Tausend Herkunfts-ASNs aus, doch die beobachtete Liste enthält höchstens 1.000 Zeilen. Das ist als Rangliste zur Begrenzung der Dateigröße plausibel. Im README wird sie aber weder als gekürzt bezeichnet noch mit einem Auswahlkriterium versehen. Die sichtbaren Zeilen sind deshalb kein Ersatz für die Dienstpopulation.

Fertig veröffentlicht ist nicht fertig abgesichert

Die offizielle prop-167-Seite zeigt weiterhin Implemented und datiert „Implementation Complete“ auf den 30. Juni 2026. Gleichzeitig hat APNIC eine Präsentation für die am 10. September geplante Policy-SIG-Sitzung bei APNIC 62 veröffentlicht. Dort steht prop-167 auf „In Implementation“. Die Statistik sei am 30. Juni erstmals publiziert worden, einige Probleme mit der Datengenauigkeit würden gelöst, und der Abschluss werde bis Ende des dritten Quartals erwartet.

Zwei Grenzen dürfen nicht verwischt werden. Die Präsentation wurde vor der geplanten Sitzung gesichert. Sie ist ein veröffentlichtes Vortragsdokument, keine bereits gehaltene Aussage. Zudem benennt sie die hier untersuchte Rechnung nicht. Es wäre unzulässig, APNIC eine konkrete Diagnose zuzuschreiben, die das Dokument nicht enthält.

Der Materialvergleich liefert dennoch eine brauchbare Schichtung. „Implemented“ kann die Verfügbarkeit des Dienstes beschreiben. „In Implementation“ kann die noch laufende Absicherung der Daten beschreiben. Verfügbarkeit, Abdeckung, Konsistenz und Korrekturfähigkeit sind unterschiedliche Meilensteine. Ein einziger Projektstatus sollte sie nicht zu einer scheinbaren Entscheidung zusammenpressen.

Ein still gewählter Nenner wird zur öffentlichen Aussage

Der offene Feed ist nützlich. Er erlaubt Studien zu Volumen, Typenmix, ASN-Konzentration und Quellvielfalt, ohne einzelne IP-Adressen oder Zielobjekte zu veröffentlichen. Die stündliche Aufbewahrung ermöglicht Nachprüfbarkeit. Dass die Differenz gefunden werden kann, ist ein Ergebnis institutioneller Offenheit und kein Argument für weniger Daten.

Jede Weiterverwendung entscheidet sich jedoch für einen Nenner. Eine ASN-Zeile geteilt durch total_queries liefert einen anderen Anteil als dieselbe Zeile geteilt durch die Typensumme. Eine Zeitreihe aus dem Gesamtfeld kann sich anders bewegen als eine aus den Typen rekonstruierte Reihe. Wenn sich nur der Klassifikator ändert, kann ein Diagramm fälschlich neues Nutzerverhalten zeigen.

Aus den Dateien folgt weder Verlust noch Duplizierung, Missbrauch, falsche Antwort, Datenschutzverletzung oder Netzschaden. Eine nicht ausgeglichene ASN-Zeile macht den ASN nicht zum Verursacher. Die Nullstunde ist ohne unabhängige Dienstmeldung kein Ausfallbeleg. Untersucht wird die Beweiskraft des öffentlichen Artefakts, nicht die gesamte WHOIS-Leistung.

Eine datenschutzfreundliche Überleitungsrechnung

Für jede Stunde genügt ein kleiner Nachweis. Er nennt zuerst die an der äußeren Grenze angenommenen Anfragen, dann erfolgreich geparste Befehle und Klassifikationsinkremente. Ausschlüsse werden in breiten Gruppen erfasst: ungültige Syntax, nicht unterstützter Typ, Zeitüberschreitung oder sonstiger Grund. Wenn eine Anfrage mehrere Typen erhöht, wird die Regel genannt. Wenn Zähler zu verschiedenen Zeiten schließen, werden beide Zeitpunkte und die Behandlung später Ereignisse angegeben.

Danach folgt die Identität der Verarbeitung: Laufkennung, Version von Erfassung und Klassifikator, Abschlusszeit und Ergebnis einer automatischen Prüfung aller Gleichungen. Fehlgeschlagene ASN-Zuordnungen können aggregiert bleiben. Die Begrenzung auf 1.000 Zeilen wird als Rangliste mit Auswahlregel bezeichnet.

Schließlich braucht jede Korrektur eine Spur. Eine Datei erhält den Zustand vorläufig, validiert, korrigiert oder zurückgezogen sowie einen Fingerabdruck. Eine Ersatzversion nennt den früheren Fingerabdruck, Korrekturzeit, Grundklasse und betroffene Felder. Die alte Fassung bleibt auffindbar, damit frühere Analysen rekonstruiert werden können.

Dieser Nachweis legt keine Quell-IP und kein abgefragtes Objekt offen. Er erklärt nur den Übergang zwischen zwei aggregierten Zahlen. APNIC hat die teuren Voraussetzungen bereits geschaffen: regelmäßige Veröffentlichung, freien Zugang, Archivierung und Integritätskontrolle. Die Überleitung macht daraus langfristig verwendbare Evidenz.

Quellen