Zusammenfassung

  • AS210860 (as-name 'edeka_digital') ist seit dem 26. März 2026 nicht mehr in der globalen Routingtabelle sichtbar; Hurricane Electric verzeichnet null angekündigte Präfixe, das einzige historisch stammende IPv4-Präfix war 193.21.248.0/21, beschrieben als EDEKA DIGITAL GmbH, mit einem beobachteten Peer, AS9211 (Nawork Internet Informationssysteme GmbH) (Hurricane Electric).
  • CIDR Report führt das ASN als 'EDEKA_DIGITAL, DE' und als NICHT angekündigt (CIDR Report); IPinfo stuft es als 'Inactive' mit 0 Präfixen ein, Halter 'EDEKA Verwaltungs- und Beteiligungs GmbH', Registry RIPE, erstellt 24. August 2021 (IPinfo).
  • Demgegenüber erklärt ein PeeringDB-abgeleiteter Eintrag, gespiegelt von HostDir, zehn IPv4-Präfixe, ein IPv6-Präfix und eine offene Peering-Richtlinie (PeeringDB, HostDir) — ein Widerspruch zu jeder unabhängigen Routingbeobachtung.
  • Das Rollenobjekt 'DFINFRA' (nic-hdl DA9499-RIPE), Hamburg, Maintainer EDDI-MNT, erstellt am 10. Juni 2021, ist laut nicht geschwärzten Drittmirrors als admin-c und tech-c von AS210860 eingetragen (ip.cc); der autoritative RIPE-REST-Endpunkt für DA9499-RIPE war in dieser Recherche nicht abrufbar (RIPE REST), und gefilterte Ausgaben zeigen DUMY-RIPE. Die Identität ist damit spiegelbasiert, nicht primär verifiziert.
  • Spiegel widersprechen einander im Organisationsnamen ('EDEKA DIGITAL GmbH' bei ip.cc versus 'EDEKA Verwaltungs- und Beteiligungs GmbH' bei whois.ipip.net, zuletzt geändert 2026-05-13) und im beobachteten Peer (AS32787 Akamai bei ip.cc versus AS9211 Nawork bei Hurricane Electric) (whois.ipip.net).
  • Der RIPEstat-Endpunkt für angekündigte Präfixe lieferte in dieser Recherche keine Nutzdaten; die Null-Präfix-Aussage stützt sich daher auf Hurricane Electric, CIDR Report und IPinfo (RIPEstat). checkip.com verzeichnet 'Status Active' ohne Präfixe, was jeder Routingbeobachtung widerspricht (checkip.com).

Das Kernbild ist ein auseinanderlaufender Datensatz: Die Datenebene (Routingbeobachtungen) und die Registerebene (Kontaktdatensatz) erzählen unterschiedliche Geschichten. Siebzehn frühere Berichte dokumentierten Registeridentität, Routingdivergenz und fehlende kommerzielle Belege; keiner untersuchte die Incident-Response-Verantwortlichkeit des Kontaktobjekts. In keinem einbehaltenen öffentlichen Quelltext erscheint eine Störungs-, Ausfall- oder Abuse-Notiz von oder über DFINFRA; das Fehlen solcher Notizen in diesem Korpus ist kein Beweis des Fehlens selbst.