Summary

  • 2020年12月3日、Matt NordhoffとPeter van Dijkがripe.net内の一部の名前の解決不具合をRIPE NCCに知らせた。Anand Buddhdevは後に、署名ソフトが余計なNSECレコードを残したと説明した。
  • RIPE NCCは中央欧州時間20時ごろゾーン全体を再署名して復旧させ、開発者への報告と監視強化を表明した。

DNSの障害を最初に見つけたのは、運用者の外にいた二人だった。2020年12月3日の15時40分ごろ、Matt NordhoffとPeter van Dijkは、ripe.net内の一部の名前が正しく解決できないとRIPE NCCに伝えた。翌日、Anand BuddhdevはDNS作業部会への報告で二人の名を挙げ、調査で判明した原因を書いた。ゾーン更新によって一部のアドレスレコードの扱いがglueレコードに変わった。DNSSECの署名ソフトはその変化を正しく処理できず、余計なNSECレコードを残した。その結果、検証に失敗した。

glueは委任先のネームサーバーへたどり着くための手掛かりで、NSECは存在しない名前について署名付きで示す仕組みの一部だ。RFC 4035は、検証する側が署名されたDNSデータをどう扱うかを定める。ゾーン内の証明が矛盾すれば、検証するリゾルバーは答えを受け取らない。厳格な門番は仕事をしていた。門の内側に置かれた書類の組み合わせが壊れていた。

RIPE NCCは20時ごろ、署名ソフトにripe.netゾーン全体を署名し直させた。Buddhdevによれば、これで問題は解消した。最初の通報から復旧まで、公開された時刻の間隔は約4時間20分。RIPE NCCの12月の会員向け更新も、このDNSSEC検証障害をサービス関連の出来事に挙げている。

報告には後始末もある。RIPE NCCは署名ソフトの開発者に問題を伝え、同様の異常を早く検知する監視を追加すると述べた。影響を受けた利用者数や修正パッチの完成までは記録していない。残るのは十分に具体的な手順だ。レコードの役割変更が署名済みゾーンを乱し、外部からの指摘を受け、全体の再署名で復旧した。番号を管理する組織も、その番号に関する名前を動かすコードの細部に足を取られる。