Zusammenfassung

  • Das RIPE-Rollenobjekt DFINFRA (nic-hdl DA9499-RIPE) ist weiterhin als administrativer und technischer Kontakt von AS210860 im RIPE Database eingetragen, obwohl das Netz seit dem 26. März 2026 keine Präfixe mehr ankündigt.
  • Eine PeeringDB-abgeleitete Aufzeichnung behauptet weiterhin zehn IPv4-Präfixe und eine offene Peering-Politik – eine selbstdeklarierte Marktoberfläche ohne beobachtbares Routing dahinter.
  • Der Verifikationsaufwand liegt dezentral bei jedem Gegenparteien-Prozess: Wer AS210860 als Peer, Transitkunden oder Datenquelle prüfen will, muss Registry, Routingdaten und Selbstdarstellung manuell abgleichen.
  • Keine der bewahrten Quellen zeigt eine öffentliche, systematische Abhilfe; die falsifizierenden Bedingungen sind präzise definierbar.

Der Zustandsunterschied

Die Registrierung von AS210860 ist nicht verschwunden. Ein Blick in die RIPE Database zeigt, dass das Aut-Num-Objekt fortbesteht und dass das Rollenobjekt DFINFRA mit dem nic-hdl DA9499-RIPE als administrativer und technischer Kontakt verzeichnet bleibt. Routingbeobachtungen zeichnen ein anderes Bild: Der CIDR Report für AS210860 zeigt keine aktiven Ankündigungen, und auch ioda.inetintel.cc.gatech.edu verzeichnet für das autonome System keine Routingaktivität. Seit dem 26. März 2026 hat das Netz keine Präfixe mehr bekannt gegeben.

Dem steht eine werbliche Selbstdarstellung gegenüber. ipinfo.io ordnet das Netz der EDEKA Digital zu, und hostdir.net führt die Aufzeichnung unter diesem Namen. Ein PeeringDB-abgeleiteter Eintrag erklärt sich weiterhin mit zehn IPv4-Präfixen und einer offenen Peering-Politik. Die Diskrepanz ist das Kernphänomen: eine Marktoberfläche, die Angebot signalisiert, wo die beobachtbare Realität seit einem halben Jahr Schweigen anzeigt.

Wer DFINFRA ist – und wer nicht

Frühere Berichterstattung von BTW hat die Identitätsfrage bereits behandelt: Das Rollenobjekt DFINFRA ist kein Handelsregisterobjekt und keine eigenständige Gesellschaft, sondern ein Datenbankhandle im RIPE-Registry; das Verzeichnisprofil von BTW dokumentiert die Eigenschaft. Handelsregisterkundungen zeigen, dass hinter dem operativen Umfeld des Netzwerks die EDEKA Verwaltungs- und Beteiligungs GmbH mit Sitz in Hamburg steht, eingetragen unter HRB 90516 in der Norddeutschen Registrierung (North Data). Wichtig ist die Trennung: Die Existenz eines registrierten Unternehmens beweist nichts über die Routingrealität des autonomen Systems, und umgekehrt beweist das verstummte Routing nichts über die Registrierung. Beides ist wahr und betrifft verschiedene Verifikationsfragen.

Die fragmentierte Beweislage

Die Aufzeichnungen Dritter über AS210860 widersprechen einander nicht zufällig, sondern systematisch entlang ihrer Datenquellen. Weris-Dienste wie whois.ipip.net spiegeln Registry-Zustände. Routingdatenbanken wie bgp.he.net und ipv4.bgp.he.net vermischen Registry-, Routing- und Selbstdarstellungsdaten. Community-Ressourcen wie ip.cc und checkip.com aggregieren ohne sichtbare Verifikationsstufe. Jeder dieser Konsumenten übernimmt eine Oberfläche, deren Korrektheit niemand garantiert.

Die bisherige Berichterstattung von BTW dokumentiert diesen Zustand: routing-evidence-september-2026, zero-announced-prefixes und der lifecycle-ledger halten die Routinglage, das Ankündigungsdatum und die Registrierungslage einzeln fest. Ergänzende Analysen behandeln die Registry-Signal- und Verifikationsgrenze, das Registry-Signal der operativen Kontrolle und die fehlende Verbindung zwischen Registrierung und operativer Kontrolle in missing-link-registration-operational-control. Diese Materialien beantworten, was beobachtet wurde; sie beantworten nicht, wer verifizieren sollte.

Das ökonomische Problem: dezentralisierte Prüfkosten

Ein Registry-Eintrag ist ein günstiges Signal. Er auszugeben kostet Minuten; seine Falsifikation kostet jeden Konsumenten eine eigene Prüfung. Diese asymmetrische Kostenstruktur erklärt, warum der Zustand anhalten kann, ohne dass irgendeine Partei ihn öffentlich korrigiert: Der Verursacher der Oberfläche hat keinen Anreiz zur Aktualisierung, und jeder einzelne Konsument trägt nur einen Bruchteil des Gesamtschadens, den die veraltete Oberfläche verursacht. Genau deshalb überdauert das Registry-Signal das Netzwerk, das es beschreiben sollte.

Die falsifizierenden Bedingungen sind präzise: Würde AS210860 wieder Präfixe ankündigen, verlöre die Diskrepanz ihre Grundlage. Würde das Rollenobjekt gelöscht oder neu zugewiesen, verschwände das Registry-Signal. Und würde eine registrierte Partei öffentlich erklären, dass die PeeringDB-abgeleiteten Angaben – zehn IPv4-Präfixe, offene Peering-Politik – nicht mehr zutreffen, läge eine verifizierte Korrektur vor. Bis zu einem dieser Ereignisse bleibt der Zustand: Registrierung bestehend, Routing verstummt, Selbstdarstellung unverändert.