要約

  • RIPE Databaseは10月28日、約8時間にわたり断続的に更新を処理できなかった。逆引きDNSの要求も対象になった。
  • RIPE NCCの後続調査によると、失敗した要求は委任を変更しない内容か、Zonemasterの検査に通らない内容だった。

逆引きDNSの状態を知るには、「更新に失敗した」という通知だけでは足りない。データベースに変更要求が届いたか、検証を通ったか、親ゾーンに反映されたかを分けて見る必要がある。10月28日のRIPE NCCの障害は、この段階の違いをはっきり示した。

RIPE NCCの状態履歴によると、RIPE Databaseの更新失敗は11:42から19:40 UTCまで断続的に続いた。20:04 CETの初報は、一部の更新とdomain objectが逆引きDNSに影響したと説明した。20:23には修正を適用して監視中と発表し、20:32に解決済みとした。

詳しい検証結果は10月30日に追加された。失敗した要求には変更内容がなかったものがあり、ほかの要求はZonemasterによる事前検査を通過しなかった。RIPE NCCは、どの要求も逆引き委任を変更する結果にはならなかったとしている。

逆引き委任はRIPE Databaseのdomain objectを通じて設定する。nserver属性が、対象ゾーンを担当するネームサーバーを指定する。RIPE NCCはDatabaseをDNSゾーンの生成に使うため、検証済みのオブジェクト変更は親ゾーンに入り、公開DNSへ反映される。

ただし、送信した要求がそのままDNSの変更になるわけではない。RIPEの手順では、データベースがネームサーバーの構成を検査し、ERRORまたはCRITICALの結果があれば更新を拒否する。更新が成功しても、委任情報がDNSに現れるまで最大24時間かかる場合がある。要求、オブジェクト、親ゾーンは別々の段階だ。

今回止まったのは要求の処理経路だった。後日の説明は、失敗した要求が変更なし、または検査不合格だったと限定している。公開された委任が変わった証拠はない。RIPE NCCは失敗した要求数と技術的な根本原因を公表していない。この二つが分かれば、障害の規模と原因をより正確に評価できる。

出典