Zusammenfassung

  • Ein RIPE-NCC-Nachtrag vom 30. Oktober datiert intermittierende Datenbankfehler auf den 28. Oktober von 11:42 bis 19:40 UTC. Die erste Meldung erklärte den Vorfall um 19:32 UTC für gelöst.
  • Laut Nachtrag hätte keine fehlgeschlagene Anfrage eine Reverse-DNS-Delegierung geändert: Sie war entweder unverändert oder scheiterte an Zonemaster-Vorprüfungen. Die Einträge weisen „major“ und „none“ als Auswirkung aus.

Die spätere RIPE-NCC-Auswertung hängt acht Minuten an den Vorfall, den die ursprüngliche Meldung bereits geschlossen hatte. Am 28. Oktober ging der RIPE Database-Dienst um 20:23 CET in die Überwachung; um 20:32 CET galt der Vorfall als gelöst. Das entspricht 19:32 UTC. Der am 30. Oktober veröffentlichte Nachtrag sagt, dass Updates bis 19:40 UTC sporadisch scheiterten.

Auch der Beginn liegt deutlich vor der ersten Warnung. Die Nachmeldung setzt ihn auf 11:42 UTC. Die Untersuchung wurde erst um 20:04 CET, also um 19:04 UTC, öffentlich angekündigt: sieben Stunden und 22 Minuten später. Die erste Meldung sprach von nicht verarbeiteten Updates und Domain-Objekten mit Auswirkungen auf Reverse DNS; ihr Impact-Feld lautet „major“.

Die spätere Prüfung grenzt die Datenwirkung ein. Keine fehlgeschlagene Anfrage hätte eine Reverse-DNS-Delegierung geändert: Manche enthielten gar keine Änderung, andere scheiterten an Zonemaster-Prüfungen vor der Delegierung. Die RIPE-Database-Dokumentation zu Reverse DNS beschreibt, wie ein Domain-Objekt die Delegierung anfordert und Nameserver geprüft werden, bevor RIPE NCC sie verbreitet.

Damit dokumentiert RIPE fehlgeschlagene Schreibversuche, aber keine durch diese Anfragen veränderte Delegierung. Im Status-API trägt der ursprüngliche Vorfall den Impact „major“, der verknüpfte Nachtrag „none“. Eine Begründung fehlt. Ebenso fehlen die Zahl der Anfragen und die betroffenen Objekte. Diese Liste würde zeigen, welche Betreiber ihre eigenen Vorgänge ohne Einzelabgleich abschließen können.

Quellen