Zusammenfassung

  • APNIC datiert den RDAP-Zwischenfall auf die 18 Stunden vom 27. Januar 2026 um 15:45 Uhr bis zum 28. Januar um 09:45 Uhr, jeweils UTC+10.
  • Eine unbeabsichtigte Änderung an der Cloudflare-Konfiguration führte laut APNIC strengere Browser-Integritätsprüfungen aus. Rund zehn Prozent der Anfragen mit User-Agent-Zeichenfolgen, die nicht üblichen Browsern entsprachen, wurden blockiert.
  • Cloudflare am Rand, DDoS-Schutz und Bot-Abwehr sind legitime Betriebsentscheidungen. Browserähnlichkeit ist aber kein Nachweis der Berechtigung eines RDAP-Clients.
  • Vier schonende Abfragen im September — ohne ausdrücklich gesetzten User-Agent, mit benannter Automatisierung, mit curl und mit browserähnlicher Kennung — erhielten dasselbe RDAP-JSON. Das ist eine aktuelle Stichprobe, kein universeller Reparaturnachweis.
  • APNIC könnte die Schutzlogik geheim halten und dennoch mit clientklassenspezifischen Tests, getrennten Rand- und Ursprungsdaten sowie einer nachvollziehbaren Änderungslinie belegen, dass das Protokoll für seine vorgesehenen Nutzer erreichbar bleibt.

Achtzehn Stunden, in denen die Verpackung entschied

APNICs Service Announcement nennt ungewöhnlich klare Eckdaten. Der Vorfall begann am Dienstag, dem 27. Januar 2026, um 15:45 Uhr und endete am Mittwoch, dem 28. Januar, um 09:45 Uhr; beide Zeitangaben gelten für UTC+10. Betroffen war der RDAP-Dienst. Die Dauer betrug 18 Stunden. Nach APNICs Darstellung löste eine Änderung an der Cloudflare-Konfiguration unbeabsichtigt strengere Browser Integrity Checks aus.

Die veröffentlichte Größenordnung ist ebenso wichtig wie ihre Grenze. Ungefähr zehn Prozent der RDAP-Anfragen, deren User-Agent-Zeichenfolgen nicht zu üblichen Browser-Zeichenfolgen passten, wurden in diesem Zeitraum blockiert. APNIC nennt weder die absolute Zahl der Requests noch betroffene Programme, Personen oder Organisationen. Auch Statuscodes, Antwortkörper, Standorte und die konkreten Zeichenfolgen bleiben unveröffentlicht.

Damit ist der sachlich haltbare Befund enger als eine Behauptung über einen vollständigen Ausfall, aber präziser als die Aussage, RDAP sei bloß „gestört“ gewesen. Ein Teil des Verkehrs wurde nach der Selbstdarstellung seiner Software unterschieden, bevor die öffentliche Beschreibung irgendeine fachliche Entscheidung des RDAP-Dienstes erkennen lässt. Ein gültiger Maschinenclient konnte auf der falschen Seite eines Webklassifikators landen.

Diese Lage erzeugt eine Beobachtungslücke. Der Ursprung kann fehlerfrei erscheinen, wenn abgewiesene Anfragen ihn nie erreichen. Ein Monitor kann Grün melden, wenn er nur einen Browser nachahmt. Und ein Anwendungsprotokoll kann aus Sicht der vorgesehenen Automation teilweise unerreichbar sein, obwohl eine interaktive Stichprobe funktioniert. Ohne getrennte Sicht auf Rand und Ursprung verschwinden diese Unterschiede in einer einzigen Verfügbarkeitszahl.

Der stärkste Einwand spricht für Schutz, nicht für Browserprivilegien

Die faire Gegenposition beginnt mit APNICs Verantwortung, den Dienst überhaupt verfügbar zu halten. Ein öffentlich abfragbares Register zieht legitime Automatisierung an, weil Automatisierung zu seinem Zweck gehört. Derselbe Zugang kann aber auch mit missbräuchlichen Raten, aggressivem Sammeln und Denial-of-Service-Verkehr belastet werden. Kein Protokollstandard verpflichtet einen Betreiber, jede beliebige Last ungefiltert bis zum Ursprung durchzureichen.

APNIC beschrieb seine RDAP-Architektur 2020 als einen Weg über Cloudflare. Der Anbieter übernimmt Lastverteilung und DDoS-Schutz für rdap.apnic.net sowie für RDAP-Dienste nationaler Internetregister, bevor Verkehr in Richtung einer in Google Cloud betriebenen Infrastruktur weitergeleitet wird. Die Schutzschicht ist folglich kein zufälliger Fremdkörper. Sie ist Teil des realen Dienstpfads, den APNIC gewählt hat.

Auch Cloudflares Dokumentation zum Browser Integrity Check beschreibt einen vernünftigen Sicherheitszweck. Das Werkzeug prüft HTTP-Header, die häufig mit missbräuchlichem Verkehr verbunden werden, und kann Anfragen mit fehlendem oder ungewöhnlichem User-Agent herausfordern. Die Dokumentation sieht außerdem vor, die Funktion über Regeln gezielt zu überspringen oder auszuschalten. Der Mechanismus ist also steuerbar und sein Einsatz kann nach Pfad und Kontext differenziert werden.

Aus dem Januar-Ereignis folgt daher weder, Cloudflare zu entfernen, noch Bot-Schutz abzuschalten, Filter offenzulegen oder unbegrenzte Abfragen zuzulassen. Die richtige Frage ist kleiner: Welche Clientklassen gehören zum versprochenen RDAP-Dienst, und welcher Betriebstest verhindert, dass eine für gewöhnliche Webseiten plausible Heuristik zur Zulassungsregel für ein Maschinenprotokoll wird?

RDAP trägt HTTP, aber sein Normalfall ist nicht der Browser

APNICs eigene Erläuterung von 2021 beschreibt RDAP als strukturiertes JSON über HTTP oder HTTPS. Antworten lassen sich maschinell verarbeiten. Einheitliche Clients können Registerdienste übergreifend arbeiten, wo traditionelle WHOIS-Ausgaben stark variierten. HTTP-Caching kann wiederholte Abfragen effizienter machen. All das benennt Automation als normale Nutzung und nicht als verdächtige Ausnahme.

Die Standards setzen dieses Bild fort. RFC 9082 definiert REST-artige Abfragepfade für Domains, Nameserver, Entitäten, IP-Netze und autonome Systeme. RFC 7480 beschreibt die Verwendung von HTTP für RDAP. Anwendungen im Browser sind möglich; die Spezifikation behandelt sogar den kontrollierten Zugriff über Ursprungsgrenzen. Daraus wird der Browser aber nicht zur privilegierten Referenzform. Kommandozeilenwerkzeuge, Bibliotheken, Inventarsysteme, Abuse-Teams und Registerprozesse sind ebenso natürliche HTTP-Clients.

Eine browserzentrierte Integritätsprüfung und ein RDAP-Endpunkt haben deshalb unterschiedliche Ausgangspopulationen. Für eine interaktive Website kann ein fehlender oder ungewöhnlicher User-Agent ein brauchbares Risikosignal sein. Für einen Protokolldienst kann dieselbe Eigenschaft lediglich bedeuten, dass ein Programm sich ehrlich als Programm ausgibt. Wird das Signal ohne passende Eingrenzung zum harten Tor, prüft es nicht die Gültigkeit der RDAP-Anfrage, sondern die Ähnlichkeit ihrer Verpackung mit einer anderen Dienstklasse.

Dieser Unterschied ist keine Spitzfindigkeit über Header. Die Schicht, die zuerst entscheidet, prägt, welche Nutzer überhaupt eine protokollgerechte Antwort erhalten können. Wenn sie einen legitimen Maschinenclient aussortiert, kann der Ursprung weder Erfolg noch Fehler zurückmelden. Die Protokollsemantik beginnt für diesen Client gar nicht erst.

Ein User-Agent ist Softwareauskunft, keine Vollmacht

RFC 9110 beschreibt User-Agent als Information über die Software, die eine Anfrage erzeugt. Die Zeichenfolge kann Produktkennungen und Kommentare enthalten. Sie hilft bei Interoperabilität, Diagnose und gegebenenfalls angepassten Antworten. Sie wird jedoch vom Client selbst geliefert, kann sparsam sein und lässt sich als anderes Produkt ausgeben.

Die Kennung authentifiziert weder den Betreiber noch seinen Zweck. Sie beweist keine APNIC-Mitgliedschaft, keinen Auftrag zur Störungsbearbeitung, keine zulässige Abfragerate und kein rechtliches Mandat. Eine Mozilla-ähnliche Zeichenfolge verleiht diese Eigenschaften nicht. Ein schlicht benanntes Skript verliert sie nicht, nur weil sein Name ungewohnt aussieht.

Der User-Agent darf als eines von mehreren Signalen in eine Schutzentscheidung einfließen. Verhalten, Rate, Reputation, Authentisierung und Kontext können ein vollständigeres Bild liefern. Gefährlich wird die Abkürzung, wenn Browserähnlichkeit allein die praktische Durchlassbedingung bildet. Dann belohnt das System gerade die Täuschung, die sein Signal entwertet: Ein gutartiger Client lernt, sich als Browser zu verkleiden, während ein bösartiger Client dieselbe Verkleidung ohnehin verwenden kann.

APNIC nennt die Wirkung unbeabsichtigt. Dieser Punkt ist wesentlich. Er liefert keinen Beleg für eine absichtliche Browserpolitik und keinen Anlass, Motive zu erfinden. Er zeigt vielmehr ein Problem der Änderungskontrolle: Eine Sicherheitskonfiguration erhielt einen Wirkungsbereich, der nicht zum Dienstvertrag passte. Genau solche Fehler lassen sich mit geeigneten Testpopulationen entdecken.

Ein verständlicher Engpass ist besser als eine falsche Identitätsprüfung

RDAP verspricht keine grenzenlose Kapazität. RFC 7481 behandelt Dienstverfügbarkeit und Widerstand gegen Denial of Service ausdrücklich als Sicherheitsbelange. Ein Betreiber kann Raten begrenzen, zusätzliche Zugänge authentisieren und den öffentlichen Dienst gegen Verdrängung schützen. Das steht nicht im Gegensatz zu maschineller Nutzung, solange eine Maschine die Antwort des Systems einordnen kann.

RFC 7480 empfiehlt für Ratenbegrenzung den HTTP-Status 429. Mit Retry-After kann ein Server mitteilen, wann ein neuer Versuch sinnvoll ist. Diese Semantik ist betrieblich wertvoll: Sie erklärt, dass die gegenwärtige Einschränkung an der Rate liegt, und ermöglicht einem Client, sein Verhalten kontrolliert anzupassen. Authentisierung kann zugleich einen tatsächlich belegten Berechtigungsunterschied abbilden.

Es wäre dennoch falsch zu behaupten, RFC 7480 habe für jeden Januar-Block zwingend 429 verlangt. Eine Bot-Herausforderung ist nicht automatisch ein Rate Limit, und APNICs Meldung enthält nicht genug Antwortdetails, um jeden Vorgang nachträglich zu klassifizieren. Der belastbare Schluss ist bescheidener: Der Betreiber sollte nach Clientklasse erkennen können, ob eine gültige Protokollanfrage am Rand in eine Herausforderung, einen Block, eine Drosselung oder eine Ursprungsantwort mündet.

Für einen automatischen Nutzer sind HTML-Zwischenseiten oder undurchsichtige Sperren keine RDAP-Daten. Ein sauberer Monitor prüft deshalb nicht nur, ob irgendein HTTP-Antwortkörper ankommt. Er prüft Statusklasse, Inhaltstyp und die Stelle, an der die Entscheidung fiel. Dadurch bleibt Schutz möglich, ohne seine Wirkung mit dem Gesundheitszustand des Registers zu verwechseln.

Vier September-Abfragen belegen einen Moment

Am 5. September 2026 wurde https://rdap.apnic.net/ip/202.12.29.0 viermal mit niedriger Rate abgefragt. Jede Anfrage verlangte application/rdap+json. Eine setzte keinen ausdrücklichen User-Agent. Eine verwendete einen zweckbezogen benannten Automatisierungs-User-Agent. Eine verwendete curl/8.7.1. Die vierte trug eine Mozilla- und Safari-ähnliche Browserkennung.

Alle vier Antworten hatten HTTP-Status 200, den Inhaltstyp application/rdap+json und einen 3.857 Byte langen Körper. Auch der SHA-256-Fingerabdruck des Körpers war identisch: d6983abd9266f7ac6d6a23b8b5cf67c186aae673a64030fc04e4e457837bb853. Die Antwortheader zeigten Cloudflare auf dem Pfad.

Das ist ein nützlicher aktueller Befund. Für genau diesen Endpunkt, diesen Netzpfad, diesen Zeitpunkt und diese schonende Rate erhielten die vier deklarierten Clientklassen dasselbe Registerergebnis. Die im Januar beschriebene Trennung ließ sich in dieser Stichprobe nicht beobachten.

Mehr trägt der Test nicht. Er wiederholt nicht die damalige Konfiguration. Er deckt keine anderen Endpunkte, Methoden, Herkunftsnetze, Regionen, Edge-Standorte oder Raten ab. Er kann nicht beweisen, dass keine andere Regel Clients unterscheidet, und garantiert keine künftige Konfiguration. Ein Canary ist ein zeitgestempelter Messpunkt, kein Zertifikat für universelle Reparatur.

Sein eigentlicher Wert entsteht durch Wiederholung. Werden dieselben Klassen regelmäßig über den tatsächlichen Randpfad geprüft, kann eine spätere Trennung als Änderung sichtbar werden. Die Stichprobe sollte daher weder als Entlastungsritual überdehnt noch als belanglos verworfen werden. Sie ist der Anfang einer Beweiskette, nicht deren Ende.

Der Dienstnachweis muss die WAF-Regel nicht verraten

APNIC könnte einen kleinen Rand-bis-Ursprung-Nachweis führen, ohne Ausdrücke, Schwellenwerte, Reputationsdaten oder Umgehungsmöglichkeiten zu veröffentlichen. Vier kontrollierte Clientklassen reichen als Anfang: kein User-Agent, eine klar benannte Automation, ein verbreiteter Kommandozeilenclient und ein Browser. Entscheidend ist, sie durch den realen Produktionspfad zu schicken.

Für jeden Canary gehören Randentscheidung und Ursprungsankunft in getrennte Felder. Hinzu kommen Statusklasse, RDAP-Inhaltstyp, Antwortklasse, Latenz und — wo tatsächlich eine Ratenbegrenzung wirkt — eine maschinenlesbare Wiederholungsanweisung. Eine Anfrage, die vor dem Ursprung blockiert wird, darf nicht aus einer rein ursprungsseitigen Erfolgsquote verschwinden.

Der zweite Teil ist die Änderungslinie: Konfigurationskennung, betroffener Hostname oder Pfad, verantwortliche Person, Review, Beginn der gestuften Ausrollung, Canary-Ergebnis, Rollback-Zeit und Abschlussprüfung. Ein öffentlicher Bericht muss die sensible Regel nicht nennen. Er sollte aber belegen können, dass eine browserbezogene Änderung nicht unbemerkt den gesamten RDAP-Pfad erfasst.

APNIC verwendet bereits eine Perspektive aus Nutzersicht. Der Bericht zur Verfügbarkeit der Registerdienste im zweiten Quartal 2025 wertet eine RDAP-Prüfung als erfolgreich, wenn innerhalb von fünf Sekunden eine HTTP-Antwort ohne Fehler eintrifft, und berechnet Verfügbarkeit aus erfolgreichen und gesamten Tests. Eine Clientklassen-Dimension würde diese Messung aussagekräftiger machen, ohne ihre Grundlage zu verwerfen.

Im Secretariat-Update für das erste Quartal 2026 heißt es, alle zentralen Registerdienste hätten mindestens 99,99 Prozent Verfügbarkeit erreicht. Der kurze Bericht nennt weder den Nenner noch genug Methodik, um diese Aussage mit dem 18-Stunden-Ereignis und seinem ungefähren Request-Anteil zu verrechnen. Es gibt keinen Grund, die Aussage für falsch zu erklären. Es gibt aber einen guten Grund, den Join zu veröffentlichen: Welche Randentscheidungen, Clientklassen und Zeitintervalle gehen in die Kennzahl ein?

Die Grenzen des Falls

Keine der geprüften Quellen zeigt, dass APNICs RDAP heute ausgefallen ist. Keine belegt, dass alle Maschinenclients blockiert wurden oder dass eine bekannte Zahl von Betreibern einen bestimmten Schaden erlitt. Die öffentliche Meldung enthält weder die genaue Liste betroffener Kennungen noch die einzelnen Antworten. Die vier September-Abfragen können diese historischen Lücken nicht füllen.

Der Vorfall beweist auch nicht, dass APNIC oder Cloudflare einen Standard missachtet hätten. RFCs definieren das Protokoll und hilfreiche Semantik; der konkrete Schutz einer Produktionsumgebung verlangt zusätzliche Entscheidungen. APNICs eigener Befund lautet, dass eine Konfigurationsänderung unbeabsichtigt wirkte. Die Verantwortungsfrage richtet sich deshalb auf Reichweite, Beobachtbarkeit und Korrektur, nicht auf eine unbelegte Regelverletzung.

Ein öffentliches Maschinenprotokoll sollte sich an seinem Vertragsverhalten erkennen lassen, nicht am Kostüm seines Clients. Dieser Satz fordert keinen schwachen Rand. Er fordert einen Rand, dessen Schutzentscheidung nicht unsichtbar eine vorgesehene Nutzerklasse ausschließt. Starker Schutz und überprüfbare Protokollverfügbarkeit sind dieselbe Betriebsaufgabe.

Quellen

  1. APNIC, Service Announcement vom 28. Januar 2026
  2. APNIC Blog, A new infrastructure to serve RDAP
  3. APNIC Blog, Is RDAP ready to replace whois?
  4. APNIC Blog, APNIC registry services availability during Q2 2025
  5. APNIC Blog, APNIC Secretariat Q1 2026 update
  6. Cloudflare Docs, Browser Integrity Check
  7. RFC 7480, HTTP Usage in RDAP
  8. RFC 7481, Security Services for RDAP
  9. RFC 9082, RDAP Query Format
  10. RFC 9110, HTTP Semantics