Zusammenfassung

  • Am 28. Oktober wurden Updates in der RIPE Database fast acht Stunden lang zeitweise nicht verarbeitet; Reverse-DNS-Anfragen waren eingeschlossen.
  • RIPE NCC kam später zu dem Schluss, dass keine dieser fehlgeschlagenen Anfragen eine Delegation geändert hätte: Manche enthielten gar keine Änderung, andere scheiterten an Zonemaster.

Bei einem Datenbankfehler sind drei Fragen zu trennen: Wurde eine Anfrage angenommen? Wurde das Objekt geändert? Ist die Delegation im DNS erschienen? Der Vorfall vom 28. Oktober zeigt, warum diese Zustände nicht in einem allgemeinen Ausfallhinweis verschwinden sollten.

RIPE NCC beziffert das intermittierende Updateproblem auf den Zeitraum von 11:42 bis 19:40 UTC. Die erste Untersuchungsmeldung erschien um 20:04 CET. Um 20:23 lief die Beobachtung eines Fixes; um 20:32 erklärte RIPE NCC den Vorfall für gelöst. Zwei Tage später ergänzte der Statusverlauf eine genauere Auswertung: Einige gescheiterte Anfragen enthielten keine Änderung. Die übrigen bestanden die Zonemaster-Prüfungen vor der Delegation nicht.

Eine Reverse-DNS-Delegation beginnt mit einem Domain-Objekt in der RIPE Database. Seine nserver-Attribute nennen die zuständigen Nameserver. RIPE NCC verwendet Datenbankobjekte zur Erzeugung der DNS-Zonen. Ein akzeptiertes Update kann deshalb in der übergeordneten Zone veröffentlicht und für Resolver sichtbar werden.

Zwischen Anfrage und Veröffentlichung liegt eine Prüfschranke. RIPEs Dokumentation zufolge werden Updates mit ERROR- oder CRITICAL-Prüfergebnissen abgelehnt. Selbst nach einer erfolgreichen Änderung können Delegationsdaten bis zu 24 Stunden benötigen, bis sie im DNS erscheinen. Anfrage, Objektänderung und Veröffentlichung bilden getrennte Schritte.

Im Oktober war die Verarbeitung unterbrochen. Die spätere RIPE-Auswertung sagt, dass die fehlgeschlagenen Anfragen entweder wirkungslose Wiederholungen waren oder an der technischen Schranke endeten. Eine daraus entstandene Änderung an der veröffentlichten Delegation ist nicht belegt. Die spätere Präzisierung macht den Statushinweis brauchbarer: Sie sagt, welcher Teil des Pfads ausfiel und welcher Zustand unverändert blieb.

RIPE NCC hat weder die Zahl fehlgeschlagener Anfragen noch den technischen Defekt veröffentlicht; diese Angaben würden Umfang und Ursache der Unterbrechung klären.

Quellen