Zusammenfassung

  • AS210860 ist nach Mirror-Beobachtungen seit dem 26. März 2026 ohne angekündigte Prefix; kein Verfallsdatum oder Folgezustand ist öffentlich dokumentiert.
  • Keine Registry-Value des aut-num-Objekts liegt aus erster Hand vor: die autoritative Abfrage lieferte nur eine JavaScript-Hülle; alle übernommenen Werte sind datierte Mirror-Beobachtungen, und zwei Mirrors nennen unterschiedliche org-Einträge für dasselbe Objekt.
  • RIPEstat zeigt laut Docs kein Registry-Statusurteil, sondern eine rendering-bedingte Anzeige; ein Statuswechsel kann daraus nicht abgeleitet werden.

Der Routing-Zustand: eine sechsmonatige Nulllinie

Routing-Mirrors zeichnen seit dem 26. März 2026 ein einheitliches Bild: AS210860 kündigt keine Prefix an (https://stat.ripe.net/resource/AS210860, https://ipv4.bgp.he.net/AS210860). Der CIDR-Report-Eintrag listet keine aktiven Ankündigungen (https://www.cidr-report.org/cgi-bin/as-report?as=AS210860&view=2.0), BGP-Toolkit-Seiten zeigen keine sichtbaren Routen (https://bgp.he.net/AS210860), und IP-Geolokationsdienste vermerken das ASN ohne operativen Fußabdruck (https://ipgeolocation.io/browse/asn/AS210860). Wichtig ist die zeitliche Präzision: Die Nulllinie beginnt nachweislich am 26. März 2026; über den Zustand davor und über den genauen Übergangstag sagen die Mirrors nichts aus, was die erste Partei bestätigen könnte. Weitere Drittquellen – https://ipinfo.io/AS210860, https://whois.ipip.net/AS210860 und https://ip.cc/topic/asn/AS210860/ – spiegeln dasselbe leere Routingbild, ohne einen Grund zu nennen.

Für einen Beobachter der Telekom- und Infrastrukturmärkte ist das keine Randnotiz: Ein ASN ohne Routing ist ein Buchhaltungssignal, kein Betriebsnachweis. Ob DFINFRA die Nummer zurückgezogen, geparkt oder einem Transitionsschritt zugeführt hat, ist aus dem Routing-Signal allein nicht entscheidbar – genau deshalb bleibt die Registry-Ebene der eigentliche Informationsgehalt dieses Falls.

Die Primärquelle, die keine Werte liefert

Die autoritative Abfrage über die RIPE-Datenbank-Weboberfläche für das aut-num-Objekt AS210860 lieferte in beiden Recherche-Runs im September 2026 nur eine JavaScript-Anwendungshülle ohne serverseitig gerenderte Objektwerte (https://apps.db.ripe.net/db-web-ui/lookup?key=AS210860&type=aut-num). Derselbe Befund war bereits in den Septembervorberichten des Falls dokumentiert. Auch die REST-API der Datenbank existiert als dokumentierter Abfrageweg (https://docs.db.ripe.net/How-to-Query-the-RIPE-Database/RESTful-API-Queries) – doch die übernommenen Objektwerte in diesem Bericht stammen sämtlich nicht von dieser Quelle, sondern von Mirrors.

Das hat eine methodische Konsequenz: Jede in diesem Bericht genannte Registry-Value ist eine datierte, namentlich zugeschriebene Beobachtung eines bestimmten Beobachters, nie eine gegenwärtige Registry-Fakta. Sollte die autoritative Quelle wieder lesbare Werte liefern, wären alle Mirror-Beobachtungen sofort gegen diese Quelle zu verifizieren; bis dahin bleibt die Widerspruchsmenge offen.

Zwei Mirrors, zwei org-Einträge

Konkret divergieren die Mirrors im org-Feld: Ein Mirror nennt für AS210860 einen org-Eintrag A, ein anderer einen abweichenden Eintrag B (die exakten Werte sind als datierte Mirror-Beobachtungen in der Coverage-Aufzeichnung dieses Falls dokumentiert). Die Divergenz ist nicht triviales Rauschen: Das org-Feld verknüpft ein aut-num-Objekt mit einer verantwortlichen Organisation. Zwei verschiedene Werte bedeuten, dass die Mirrors zu unterschiedlichen Zeitpunkten oder aus unterschiedlichen Objektversionen schöpfen – oder dass mindestens einer falsch liest.

Ohne aus erster Hand abrufbare Registry-Werte lässt sich nicht entscheiden, welcher der beiden Werte aktuell gültig ist. Was feststeht: Die Kontrollkette zu einer namentlichen Organisation bleibt unbewiesen. Genau dieser Befund war das Zentrum der früheren BTW-Berichte zu AS210860, und er hat sich im September 2026 nicht verändert – nur die Anzahl der dokumentierten, widersprüchlichen Beobachtungen ist gestiegen.

RIPEstat und das Wort RESERVED: eine Dokumentationsfrage

RIPEstat zeigt für AS210860 ein Zustandsrendering, das das Wort RESERVED enthält. Aus den RIPE-Datenbank-Dokumenten ergibt sich aber: Ein aut-num-Objekt besitzt Statuswerte in der Objektlogik der Datenbank, und die Anzeige von RESERVED in einem Statistik-Panel ist eine rendering-bedingte Anzeige dieser Tool-Konvention, kein von der Registry verhängter Statuswechsel. Die Dokumentation der Primärobjekte (https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-of-Primary-Objects/) beschreibt, welche Statuswerte ein aut-num überhaupt tragen kann; RESERVED als automatisches Panel-Rendering ist davon getrennt.

Die Falschinterpretation wäre hier besonders verlockend und besonders schädlich: Wer aus dem RESERVED-Panel einen Registry-Statuswechsel liest, verwandelt eine Anzeige-Praxis in einen Verwaltungsakt, der nie dokumentiert wurde. Der Befund bleibt also: kein dokumentierter Statuswechsel, nur eine beobachtete Anzeige.

Was als Nächstes beobachtet werden muss

Drei Bedingungen könnten den Zustand verändern: das Wiederauftauchen von Ankündigungen im Routing, die Wiederherstellung lesbarer Werte aus der autoritativen Quelle, oder das Konvergieren der Mirror-Org-Werte auf einen namentlichen Halter. Solange keine der drei eintritt, bleibt AS210860 ein Fall von drei Schweigen: eines Netzes, das nichts ankündigt, einer Quelle, die nichts ausgibt, und Mirrors, die sich nicht einigen.