Zusammenfassung

  • 0,006 Prozent bezeichnet Whois-Abfragefälle, in denen NONAUTH-Objekte zurückgegeben wurden; rund 20 Prozent bezeichnet NRTM-Anfragen nach NONAUTH-Updates. Es sind keine vergleichbaren Anteile von Nutzern oder Datenverkehr.
  • Die nächste Bereinigung steht erst auf „Starting“. Vor einer Löschung müssen betroffene Objekte, Regel, Benachrichtigung, Migration und Prüfung danach benannt werden.

Abfrage und Spiegelung sind zwei verschiedene Wege

Eine Whois-Abfrage sucht eine Information zu einem Zeitpunkt. NRTM liefert Datenbankänderungen, damit eine lokale Kopie aktuell bleibt. Ein Objekt kann selten in einer einzelnen Antwort erscheinen und trotzdem über einen getrennten Aktualisierungskanal angefragt werden. Das ist kein Widerspruch, sondern eine Folge unterschiedlicher Messpfade.

Am 17. Juli 2025 schrieb die RIPE NCC an die Database-WG-Liste, dass RIPE-NONAUTH-Objekte in etwa 0,006 Prozent der Whois-Abfragefälle zurückgegeben worden seien. In derselben Nachricht hieß es, ungefähr 20 Prozent der NRTM-Anfragen hätten nach NONAUTH-Updates gefragt. Die Nachricht nennt weder den Beobachtungszeitraum noch absolute Nenner oder die Zahl unterschiedlicher Spiegelkunden. Die Prozentwerte lassen sich daher weder verrechnen noch zu einer einzigen Nutzungsquote zusammenfassen.

Die kleine Whois-Zahl beantwortet eine begrenzte Frage: Wie oft wurde ein NONAUTH-Objekt in den untersuchten Abfrageantworten ausgegeben? Sie zeigt nicht, wie viele verschiedene Netze von solchen Antworten abhingen, wie wichtig diese Fälle für den Betrieb waren oder was Netze aus einem lokalen Spiegel bezogen. Auch Nutzer, die nur autoritative Quellen abfragen, werden damit nicht erfasst. Die RIPE NCC weist darauf hin, dass NONAUTH standardmäßig in Whois-Abfragen enthalten ist und ein Client nicht-autoritative Angaben verwechseln kann, wenn er das source-Attribut ignoriert. Mit „-s RIPE“ lässt sich die Abfrage auf die RIPE-Quelle begrenzen.

Die 20 Prozent beantworten eine andere Frage: Welcher Anteil der NRTM-Anfragen fragte Änderungen an NONAUTH ab? Daraus geht nicht hervor, ob viele Kunden oder wenige wiederholt abfragende Systeme dahinterstanden, ob jede Anfrage erfolgreich übertragen wurde oder ob die Daten anschließend produktiv genutzt wurden. Ein automatisierter Prozess kann häufig anfragen; ein anderer Nutzer kann stattdessen eine tägliche Datei laden. Der Prozentwert zählt weder Betreiber noch Kunden, Verkehr, Spiegel oder Abhängigkeiten.

Der Bereinigungsgrund ist nachvollziehbar; die Beweislücke bleibt

RIPE-NONAUTH wurde 2018 als separater Bestand für bestimmte nicht-autoritative Objekte außerhalb der Region eingeführt. Die RIPE NCC hat einen legitimen Grund, Daten zu reduzieren, deren Ursprung oder aktuelle Gültigkeit unbekannt sein kann. Der operative Bericht von RIPE 90 nannte im Mai 2025 weniger als 100 Änderungen pro Jahr und einen schrittweise sinkenden Bestand. Solche Hinweise rechtfertigen eine Prüfung einzelner Objekte, aber sie beweisen nicht, dass alle verbliebenen Einträge überflüssig sind.

Die Diskussionen von 2025 bezogen sich auf konkrete Regeln, etwa ein passendes gültiges ROA oder ein Route-Objekt in einer anderen RIR-Datenbank. Laut dem Entwurf der RIPE-91-Minuten verschickte die RIPE NCC gut 2.000 Benachrichtigungen an Maintainer möglicherweise betroffener Objekte. Es gingen 33 Antworten ein: 23 baten darum, ihre Objekte nicht zu löschen; mit zehn Maintainerinnen und Maintainer wurde die Nutzung besprochen und die Einrichtung einer Alternative in einer autoritativen Datenbank unterstützt. Das macht den Migrationsaufwand sichtbar, ist aber keine repräsentative Erhebung aller Verbraucher.

Antwortende können sich von Schweigenden unterscheiden, und die Rückmeldungen zählen nicht jeden Spiegel.

Bei RIPE 92 unterstützte Job Snijders das Entfernen von Routen mit passendem gültigem ROA oder Route-Objekt in einer anderen RIR-Datenbank. AMS-IX sagte, seine Route-Server nutzten NONAUTH seit Jahren nicht mehr und hätten keine Beschwerden oder betrieblichen Folgen erlebt. Das ist ein konkreter, aber auf einen Betreiber und dessen Umstellung begrenzter Bericht. Die RIPE NCC bat andere weiterhin abhängige Betreiber, sich zu melden. Die Minuten dokumentieren eine Diskussion, keinen Beschluss zur Stilllegung.

„Starting“ ist kein Löschtermin

Der am 17. September aktualisierte RIPE-Database-Plan für Q4 2026 sieht nach den Diskussionen auf der Mailingliste und bei RIPE 92 weitere Bereinigungsvorschläge vor. Der Status lautet „Starting“. Der Plan nennt weder die endgültige Objektmenge noch die Abgleichlogik, einen Termin, eine Frist, Ausnahmen oder eine Änderung des NRTM-Dienstes. Weniger Einträge bedeuten nicht, dass die Datenbank geschlossen wird; umgesetzt ist laut Plan keiner dieser Schritte.

Zu jeder Regel sollten ein datierter Bestand, die betroffenen Objekttypen, die Abgleichdefinition und die erwartete Anzahl gehören. Whois-Abfragen und NRTM-Updates müssen jeweils mit eigener Beobachtungszeit und eigenem Nenner ausgewiesen werden. Wenn die Daten es erlauben, kann zusätzlich eine datenschutzgerechte Zahl unterschiedlicher aktiver Kunden veröffentlicht werden; aus Anfragezahlen darf sie nicht abgeleitet werden. Benachrichtigte Maintainer, Antworten, abgeschlossene Migrationen und ungelöste Fälle müssen getrennt bleiben.

Dafür braucht es kein dauerhaftes Telemetrieprogramm. Nötig ist ein versionierter Beleg für eine folgenreiche Änderung am Datenpfad: Regel, Benachrichtigung, Alternative, Übergangsfrist, begrenzter Test und ein Kriterium zum Anhalten, falls das beobachtete Verhalten abweicht. Exakte Duplikate zu entfernen ist eine andere Entscheidung als alle durch ein gültiges ROA abgedeckten Objekte zu entfernen. NRTM abzuschalten wäre eine dritte. Wer all das unter „Nutzung“ zusammenfasst, nimmt der Entscheidung genau die nötigen Unterscheidungen.

Quellen