Zusammenfassung

  • Der öffentliche PeeringDB-Eintrag für AFRINICs ASN 33764 nennt weiterhin AS-AFRINIC ohne Quellenpräfix; die 2026 angekündigte Änderung soll mehrdeutige IRR-Verweise besser auflösbar machen.
  • Ein Präfix kann auf die Datenbank für eine Suche verweisen. Es belegt weder den Inhalt und die Berechtigung des Sets noch dessen Aktualität oder Eignung für einen Routenfilter.

Ein Verweis ist kein Prüfprotokoll

Der PeeringDB-Netzwerkeintrag 3803 führt AFRINIC, ASN 33764 und das IRR-AS-SET AS-AFRINIC. Die öffentliche API liefert denselben Wert im skalaren Feld irr_as_set. Auf der Seite erscheint außerdem „IRR AS-SET Verified“. Das dokumentiert, was PeeringDB anzeigt. In den geprüften öffentlichen Angaben findet sich jedoch kein Prüfprotokoll, das die abgefragte IRR-Datenbank, den Zeitpunkt, den Umfang der Prüfung oder die zurückgegebenen Mitglieder nennt.

Auch die Zeitstempel müssen getrennt bleiben. Das allgemeine updated des Netzwerkeintrags ist der 2. Mai 2025. Für die Peering-LAN-Daten steht separat netixlan_updated mit dem 26. März 2026. Der neuere Zeitstempel des Unterdatensatzes belegt keine Änderung des AS-SET-Felds an diesem Tag. Umgekehrt macht das ältere Datum den ganzen Netzwerkeintrag nicht nachweislich veraltet. Eine eigene Änderungs- oder Prüfgeschichte für das IRR-Feld ist öffentlich nicht ausgewiesen.

PeeringDBs Änderung behandelt ein engeres Problem. Issue #1973 schilderte Namen ohne erkennbare Quelle, Namen in mehreren IRRs und die manuelle Prüfung, die einer Automatisierung vorausging. Die Versionshinweise zu 2.82.0 vom 19. August nennen einen intelligenten AS-SET-Editor, proaktive Korrekturen bei eindeutiger Quelle und die Kontaktaufnahme mit Netzwerkverantwortlichen, wenn die Quelle unklar ist. Die September-Zusammenfassung verwendet AFRINIC::AS-AFRINIC als Beispiel für die qualifizierte Form und beschreibt die Nachfrage bei Zweifeln. Das belegt eine Produktänderung und einen Bereinigungsprozess; warum genau dieser öffentliche Eintrag noch den unqualifizierten Namen führt, erklären die Quellen nicht.

Der Name ist nicht der Inhalt

Ein AS-SET-Name verweist auf einen RPSL-Eintrag; er enthält keine Kopie seiner Mitglieder. RFC 2622 beschreibt ein as-set, dessen Mitglieder AS-Nummern oder weitere AS-SET-Namen sein können. Ein Verbraucher des PeeringDB-Felds kann damit ein IRR auswählen, den Eintrag abrufen, verschachtelte Verweise auflösen und anschließend einen Filter erzeugen. Gibt es denselben Namen in mehreren IRRs, kann das Quellenpräfix die erste Abfrage eindeutiger machen.

Das ist ein konkreter Fortschritt bei der Suche. Eine Ende-zu-Ende-Prüfung ist es nicht. Das Präfix beweist weder, dass der Eintrag noch existiert, noch dass seine Maintainer autorisiert sind, noch dass die Mitglieder den beabsichtigten Kunden entsprechen oder die rekursive Auflösung vollständig war. Ebenso wenig regelt es den Umgang mit Verweisen, verzögerten Spiegeln oder widersprüchlichen Kopien. Aus dem Namen allein folgt nicht, dass die fertige Routing-Policy der Absicht des Betreibers entspricht.

Der Unterschied kann praktisch werden. Wählt ein automatisierter Prozess das falsche IRR oder erhält ein leeres oder unvollständiges Set, kann er einen Filter erzeugen, der erwartete Routen ausschließt oder unerwünschte zulässt. PeeringDBs Issue nennt Fehler in Filter-Policies als mögliche Folge mehrdeutiger Namen. Diese Recherche belegt jedoch keinen solchen Fehler bei ASN 33764, keinen Defekt im AFRINIC-IRR und keine Verwendung dieses Eintrags in einem aktiven Filter. Ein plausibler Wirkungsweg ist noch kein dokumentierter Vorfall.

Die Übergabe belegen

Ein sicherer Ablauf sollte den PeeringDB-Eintrag samt Version, die gewählte IRR-Quelle, den Abfragezeitpunkt, den Bezeichner des zurückgegebenen Eintrags, die Mitgliederzahl nach der Auflösung und einen Ergebnis-Hash speichern; anschließend gehört der Test der erzeugten Policy dazu. Eine Kennzeichnung „verified“ kann nützlich sein. Für eine belastbare Entscheidung braucht der Nutzer aber ihren Umfang und Zeitpunkt. Seite und API zeigen Label und Wert, nicht diese Beweiskette.

AFRINIC::AS-AFRINIC bedeutet daher, sofern es erscheint, nur: Dort soll gesucht werden. Es garantiert nicht die Antwort. Der unqualifizierte Wert im AFRINIC-Eintrag macht sichtbar, dass Verzeichnis, IRR-Eintrag und Routingentscheidung auf unterschiedlichen Kontrollebenen liegen. Ein Präfix kann die Übergabe klarer machen; der Verbraucher muss weiterhin nachweisen, was er erhalten hat.

Primärquellen: PeeringDB Issue #1973, Versionshinweise zu 2.82.0, PeeringDB-Update für September, AFRINIC-Netzwerkeintrag, öffentliche API, API-Spezifikation und RFC 2622.