Zusammenfassung

  • Im kumulativen APNIC-Transferoriginal vom 3. November steht der Übergang von 202.89.220.0–202.89.223.255 am 2. November 2026 um 23:38:39 UTC: von Indonesia Network Information Center/dnk-id an Indonesia Network Information Center/SCBD-ID. Das sind 1.024 Adressen. Die erweiterte Datei vom 3. November enthält noch einen /20 mit 4.096 Adressen; die vom 4. November teilt ihn in einen /21 und zwei /22. Der übertragene /22 hat darin eine eigene und von den anderen abweichende Inhaberkennung.
  • APNIC-WHOIS für den übertragenen Bereich liefert zuerst das genaue Kindobjekt SCBD-NET mit Änderungszeit 23:38:47 UTC und danach den alten IDNIC-Elternblock DNK-NET. RDAP für denselben /22 liefert nur das /20-Elternobjekt. Die acht Sekunden zwischen Transfer- und WHOIS-Zeitstempel sind zwei protokollierte Verwaltungszeiten, keine gemessene Verteilungsdauer.

Die Buchhaltung lässt sich ohne Schätzung rekonstruieren. Am 3. November steht 202.89.208.0 mit 4.096 Adressen in einer Zeile, dem kompletten 202.89.208.0/20. Am 4. November stehen dort drei disjunkte Zeilen: ein /21 ab .208.0 mit 2.048 Adressen, ein /22 ab .216.0 mit 1.024 und ein /22 ab .220.0 mit weiteren 1.024. Zusammen sind es wieder 4.096. Die letzte Zeile entspricht dem Bereich im Transferprotokoll. Wer die drei Zeilen als neue Adressen zusätzlich zum alten /20 zählt, produziert Papierwachstum statt Netzressourcen.

Die Kennungen machen die Grenze innerhalb eines Tages sichtbar. Die ersten beiden 4.-November-Zeilen tragen A92AB1BD, die letzte A92B4C5C. Das offizielle README für erweiterte Dateien ordnet gleiche opaque IDs innerhalb einer Datei demselben Ressourceninhaber zu. Es warnt zugleich, dass die Zeichenfolge zwischen Dateiversionen nicht stabil sein muss. Hier zählen also die zwei verschiedenen Kennungen in derselben Datei. Die Namen der Parteien entnimmt man dem Transferoriginal, nicht einem Versuch, die Codes wie Firmenregister-Nummern zu lesen.

Das Transferoriginal benennt dnk-id als Quelle und SCBD-ID als Empfänger. APNICs Definition des Logformats beschreibt die Felder für Parteien, Ressource und Datum. Ein Kaufpreis oder Routerwechsel steht dort nicht. In allen drei neuen Statistikzeilen bleibt das Datum 20050419. Laut RIR-Statistikaustauschformat bilden Tagesdateien den gegenwärtigen Delegationsstand ab, ohne Transaktionsgeschichte. Der 2005er Stempel gehört zur ursprünglichen Delegation; der 2026er Transfer hat einen eigenen Beleg.

Das WHOIS liefert den Weg von Codes zu benannten Objekten. Für den linken /21 erscheint zuerst das exakte DNK-NET-Objekt. Der mittlere /22 hat ebenfalls ein genaues DNK-NET-Objekt. Der übertragene /22 beginnt dagegen mit SCBD-NET. Alle drei Kindobjekte vermerken last-modified: 2026-11-02T23:38:47Z, acht Sekunden nach dem Transferzeitpunkt. Danach zeigt jede WHOIS-Antwort noch das alte, umfassende /20 DNK-NET, source: IDNIC, zuletzt 2011 geändert. Beide Ebenen stehen öffentlich nebeneinander.

Die drei RDAP-Aufrufe schrumpfen dieses Nebeneinander auf den Elternblock. Links /21, mittig /22 und übertragen /22 antworten jeweils mit 202.89.208.0–202.89.223.255 und dem Namen DNK-NET. Die Hinweise nennen IDNIC als Quelle und eine teilweise Spiegelung durch APNIC. Die präzisen APNIC-Kinder aus den WHOIS-Antworten erscheinen in diesen RDAP-Ergebnissen nicht. Daraus folgt eine öffentliche Suchlücke, keine Aussage darüber, welches Netz das Präfix ankündigt oder wer eine Beschwerde tatsächlich bearbeitet.

Der APNIC-Leitfaden zum Transferlog empfiehlt, die Empfängerhaltung im Whois Database anhand des Präfixes zu prüfen. Diese Prüfung funktioniert, wenn man das Kindobjekt liest und vom mitgelieferten IDNIC-Elternobjekt trennt. Ein RDAP-Client bekommt hier nur den Elternblock. Die Information ist nicht verloren; die einfachste Abfrage zielt an ihr vorbei.