要約

  • RIPE NCCの記録では、NRTMの問題は8月2日00:06 UTCから8月4日12:30 UTCまで続いた。60時間24分の間に逆引きDNSの更新が遅れ、修正後に保留分が処理された。
  • RIPE 93でEd Shryaneは、エスケープ文字の復号が余分な改行を生み、RPSLオブジェクトを構文的に無効にしたと説明した。修正では文字をそのまま残し、直近1,000件と応答末尾を検査した。

分析

RIPE Databaseのドメインオブジェクトを更新しても、その変更がグローバルDNSに届かない。2026年8月、止まったのはDNSの設定作業そのものではなく、データベース変更を運ぶNRTMの経路だった。RIPE NCCの逆引きDNSプロビジョニングも、このミラーサービスを使っている。

RIPE NCCが8月6日にDatabase Working Groupへ送った報告によると、影響期間は8月2日00:06 UTCから4日12:30 UTCまで。60時間24分だ。報告は、この間にグローバルDNSへの更新が遅れ、NRTMを直した後に保留中の更新をすべて処理したとしている。RIPEのステータス記録は重大インシデントと分類し、後の更新でドメイン変更の公開処理と逆引きDNSの復旧を伝えた。

RIPE DatabaseのエンジニアEd Shryaneは、RIPE 93のDatabaseセッションで原因を説明した。エスケープ文字を戻す処理によって、RPSLオブジェクトに余分な改行が加わった。その結果、RIPE NCCが受け入れたオブジェクトは構文上無効になった。RPSLの仕様を定めるRFC 2622では行の構造が意味を持つ。デコード処理は文字を見やすくするだけの操作ではなく、ミラー側が読む構造そのものを変えていた。

修正ではエスケープ文字を復号せず、そのまま保持した。さらに直近1,000件をさかのぼり、正しく解析できるか、NRTM応答の終端フッターが一貫しているかを確認した。データの一部を読めることと、応答全体が終わったと判断できることは別の検査だ。

データベース、ミラー、逆引きDNSのプロビジョニング、公開ゾーン。変更はこの順で届く。登録情報の変換ミスが最後の公開を遅らせた。RIPEの公開記録には時間と復旧状況があるが、影響したミラーやドメインの数はない。その数が分かれば、外部への影響規模の見積もりは変わる。

出典

RIPE 93 Databaseの文字起こし；RIPE 93のセッションページ；RIPE NCCの障害記録；RIPE NCCのDatabase Working Group向け報告；RFC 2622。