Zusammenfassung

  • Der BTW-Eintrag zu Netnod AB hat genau zwei Belegeinträge, beide zeigen auf dieselbe RIPE-NCC-URL; die 0,82 misst das Vertrauen in die eigene Karte, nicht die Qualität des Betreibers.
  • Die am 29. Oktober 2026 festgehaltenen Betreiberseiten nennen 200+ Netze und 3+ Tbps an sieben nordischen Standorten, den seit 2000 betriebenen Rootserver i.root-servers.net und eine Eigentümerschaft durch die gemeinnützige Stiftung TU-stiftelsen.
  • Zwei Autonome Systeme erscheinen im festgehaltenen Material: 8674 im zitierten Auszug, 213 nur in der Zusammenfassungsschicht des Abrufs. Für keines davon liegt zu diesem Datum ein Registerbeleg vor.
  • Was das für Entscheider heißt: Wer peert, DNS-Dienste einkauft oder eine Resilienzklausel schreibt, darf diese Oberflächen nicht als getrennte Fehlerdomänen voraussetzen.

Eine ehrliche, aber schmale Karte

Der Netnod-AB-Eintrag im BTW-Verzeichnis ist in einer Minute gelesen und hinterlässt eine vernünftige Frage. Der Titel lautet Netnod AB, der Slug netnod-ab-se, der Entitätstyp COMPANY, die Region SE, der Status PUBLISHED. Quellsystem ist das RIPE-NCC-Mitgliederverzeichnis, der letzte Import erfolgte durch den RIR-Mitgliederverzeichnis-Import.

Der entscheidende Punkt steckt im Belegapparat. Die Karte enthält genau zwei Einträge in ihrer Belegbasis, beschriftet „RIPE NCC member directory record“ und „RIPE NCC member detail page“, und beide verweisen auf dieselbe Adresse: die Mitgliederliste des RIPE NCC für Schweden. Eine einzige Register-URL, zweimal gezählt. Die Karte verschweigt das nicht — und sie sagt auch, was sie nicht ist: known_role und why_tracked beschreiben eine Mitglieds- und Ressourceninhaber-Spur gegenüber einem RIR samt amtlichem Dienstbereichskontext, nicht den Nachweis, dass das Unternehmen ISP-, IP-Transit-, Cloud-, Registry- oder Managed-Network-Dienste verkauft.

Die 0,82 bewertet nicht den Betreiber. Sie ist die Konfidenz, die BTW in das eigene Artefakt hat. Ein hoher Wert auf einer Karte aus einer einzigen Quelle bleibt eine Karte aus einer einzigen Quelle.

Das Feld data_gaps derselben Karte ist ausgesprochen offen und brauchbar. Es verlangt, Rechtsregistrierung, öffentliche Website und Führungskontakte aus amtlichen oder handelsregisterlichen Quellen zu prüfen; ASN und IP-Ressourcen über RDAP, WHOIS, IRR, BGP oder RIR-Delegationsdaten zuzuordnen, bevor irgendeine Aussage zur Routing-Präsenz gemacht wird; und das Unternehmen nicht als ISP, Transit-, Cloud-, Registry- oder Managed-Network-Anbieter einzuordnen, solange keine aktuelle öffentliche Quelle das ausdrücklich trägt. Mit anderen Worten: Die Karte verbirgt die Distanz zwischen einer Mitgliedszeile und einem laufenden Netz nicht.

Sie benennt sie.

Drei Oberflächen auf den Betreiberseiten

In der am 29. Oktober 2026 festgehaltenen Fassung beschreiben die Betreiberseiten ein Geschäft, das deutlich größer ist als eine Mitgliedschaft. Auf der Seite des Austauschpunkts behauptet ein festgehaltener Auszug, das Unternehmen betreibe „the largest Internet Exchange (IX) in the Nordics with 200+ networks exchanging 3+ Tbps of traffic“, bezeichnet sich als führenden IX-Anbieter der nordischen Region und verortet Teilnehmer „at seven different locations across the Nordic“.

Auf der I-root-Seite hält ein Auszug fest, dass das Unternehmen seit 2000 i.root-servers.net betreibt, „the first root server to be located outside of the United States“, und das I-root-Anycastnetz fortlaufend erweitert. Derselbe Auszug endet mit einer Klammer: „(ASN 8674)“.

Auf der Unternehmensseite beschreibt ein Auszug die Organisation als „neutral and independent“, mit Sitz in Schweden, und als „fully owned by the non-profit foundation TU-stiftelsen (Stiftelsen för Telematikens utveckling)“.

Und im Betreiberverzeichnis der Rootserver nennt ein Auszug die strukturelle Tatsache des Systems: „The 13 root name servers are operated by 12 independent organisations.“

Drei Oberflächen, vier Seiten, eine Organisation. Dazu kommt ein Leseproblem: Keine dieser Seiten wurde in dieser Recherche Wort für Wort gelesen. Jede Aussage des Betreibers ruht auf einem kurzen festgehaltenen Auszug plus einer beim Abruf mitgeschriebenen Zusammenfassungsschicht, die kein Seitentext ist. Dieser Unterschied ist kein Formalismus. Er entscheidet, was man schreiben darf.

200+ und 3+ Tbps: welche Schicht das sagt

Die Zahlen des Austauschpunkts werden am häufigsten zitiert und sind am fragilsten. Die „200+“ im zitierten Auszug sind eine Zählung angeschlossener Netze. Sie sagt nichts über Verkehrssymmetrie, Redundanz oder Kundenkonzentration und ist selbstverständlich keine Kundenzahl und kein Umsatz.

„3+ Tbps“ erscheint im Auszug als Verkehrsbeschreibung in der Sprache des Betreibers. Es ist kein Durchschnitt, keine installierte Kapazität und kein Marktanteil; Messdatum, Methode und Portzahl fehlen im festgehaltenen Material.

Die „sieben Standorte“ sind die nützlichste und die unvollständigste Angabe. Sieben Punkte in der nordischen Region kommen ohne Standortliste, weshalb kein Leser erkennen kann, ob zwei davon Stromversorgung, Zuführungsglasfaser oder dasselbe Betriebsteam teilen. Die Redundanz, die eine Karte nahelegt, ist durch eine Zahl nicht belegt.

Und „largest“ wie „leading“ sind Eigenvergleiche des Betreibers innerhalb des Auszugs. Eine unabhängige Rangliste wurde in dieser Recherche nicht festgehalten. Man kann die Beschreibung als das nehmen, was sie ist — die Stimme des Hauses — ohne sie zu einer von Dritten geprüften Tatsache zu adeln.

Es gibt eine fünfte Zahl, die nur in einer anderen Schicht existiert. ASN 213 erscheint ausschließlich in der Zusammenfassung, die dem Abruf der Austauschpunkt-Seite beiliegt, mit dem Hinweis, sie stamme aus einem IX-Statistik-Schnipsel; im zitierten Text jener Seite steht sie nicht. Diese Zahl lässt sich nicht als Seitenzitat präsentieren. Wohl aber als das, was sie ist: ein Hinweis aus der Zusammenfassungsschicht, ohne Registerbeleg zu diesem Datum.

Der I-Root und der ASN 8674

Die zweite Oberfläche ist älter und institutioneller. Einen Rootserver seit 2000 zu betreiben, gehört zu jenen Pflichten, die man nicht mit Marketing ankündigt, sondern mit Stabilität. Der festgehaltene Auszug setzt den Beginn ins Jahr 2000 und beschreibt die fortlaufende Erweiterung des Anycastnetzes. Die Zahl der Anycast-Standorte — 80+ — erscheint nur in der beiliegenden Zusammenfassung, nicht im zitierten Text, und belegt ohnehin keine physische oder routingseitige Unabhängigkeit der Instanzen.

Die folgenreichste Angabe dieses Artikels steckt in einer Klammer aus drei Wörtern. ASN 8674 steht im zitierten Auszug der I-root-Seite, unmittelbar nach dem Satz über die Erweiterung des Anycastnetzes. Es ist die einzige ASN, die das festgehaltene Material über zitierten Text einer konkreten Oberfläche zuordnet.

Der Kontrast zur 213 des Austauschpunkts ist kein kleines technisches Detail und auch keine Schlussfolgerung. Zwei verschiedene Nummern können zwei verschiedene Autonome Systeme beschreiben oder zwei Erwähnungen desselben Systems in Dokumenten unterschiedlichen Datums. Das festgehaltene Material erlaubt keine Wahl zwischen diesen Lesarten, und dieser Artikel trifft sie nicht. Zu behaupten, es sei dasselbe System, oder eine Nummer sei ein Tippfehler der anderen, hieße genau die fehlende Angabe zu erfinden.

Warum die Routing-Identität zählt

Wer über das BTW-Verzeichnis zu Netnod kommt, will etwas Praktisches wissen: womit er es zu tun bekommt, wenn er abschließt, peert oder die Organisation in eine Klausel schreibt. Die Routing-Identität beantwortet das besser als jedes Organigramm.

Werden Austauschgewebe und Anycast-Rootdienst aus verschiedenen Autonomen Systemen angekündigt, haben sie unterschiedliche Upstream-Beziehungen, unterschiedliche Fehlermodi der Routenpolitik und unterschiedliche Exposition gegenüber einer einzelnen Fehlkonfiguration oder einem einzelnen Transitstreit. Teilen sie ein einziges Autonomes System, teilen sie auch den einen Punkt, an dem eine falsch angewandte Politik zwei Dienste gleichzeitig schwächt. Wer entscheidet, wählt zwischen zwei Fehlerdomänen, und der festgehaltene Registerstand sagt nicht, welche gilt.

Die Verzeichniskarte hilft hier nicht: Sie listet weder ASN noch Präfix. Ihr data_gaps-Feld verlangt genau diese Zuordnung, bevor irgendeine Aussage zur Routing-Präsenz fällt. Auch die Seitenabrufe schließen die Frage nicht, weil sie Marketingsätze und eine Klammer liefern. Und die registerliche Prüfung, die den Punkt hätte klären können, blieb unvollendet: Die Abfrage zu ASN 8674 und 213 wurde am 29. Oktober 2026 gestellt und scheiterte auf der Dienstebene an einem Berechtigungsfehler, demselben, der in dieser Recherche bereits fünf frühere Anfragen beendet hatte. Kein Registereintrag blieb erhalten.

Das beweist nicht, dass es keinen gibt; es beweist, dass dieses Datum keinen hat.

Was sich sagen lässt

Die öffentliche Legitimität Netnods hängt nicht an der Mitgliedszeile und nicht an der 0,82. Sie hängt an Oberflächen, die eine Registerzeile nicht beschreiben kann: einem Austauschgewebe mit selbst genannten Teilnehmerzahlen, einem Anycast-Rootdienst mit Betriebsgeschichte und einem Stiftungseigner. Die richtige redaktionelle Antwort ist weder, die Mitgliedschaft zu einem Betreiberprofil aufzublasen, noch die Marketingseite als Audit zu behandeln. Sie lautet: die Grenze veröffentlichen und für jede Zahl sagen, aus welcher Schicht sie stammt.

Offen bleibt, und das gehört festgehalten: ob diese Oberflächen eine einzige Routing-Identität teilen; welche konkrete Governance TU-stiftelsen über den Eigentümertitel hinaus ausübt; welche Standorte hinter den sieben nordischen Orten stehen und was sie untereinander teilen; und welche Störungs-, Audit- oder Ausfallaufzeichnungen für den Austauschpunkt oder für I-root existieren. Nichts davon war am 29. Oktober 2026 festgehalten.

Quellen