要約

  • RIPE NCCはDNSインスタンスの状態とAtlasアンカーへの到達性を使い、サービス経路の撤回と再広告を自動化した。
  • ファイアウォールの誤変更で全インスタンスが0％と表示された際、共通障害用の保護機能が最後の経路状態を維持した。
  • 公開されたのは制御機構の試験結果であり、DNS障害や利用者への影響ではない。

一つの拠点が「届かない」と示す値と、全拠点が同時にゼロを示す値は同じではない。DNSの計測器が一斉にゼロを返したとき、RIPE NCCの制御は全ての経路を引く命令と受け取らず、最後の状態を保った。観測の失敗がネットワーク操作に化けるのを止めた。

RIPE 93のDNSセッションで、RIPE NCCのLeon GrasmeijerはホステッドDNSの自動化を説明した。まず小さなデーモンがローカルDNSサーバーへ問い合わせる。応答がなければ、そのインスタンスのサービスプレフィックスを撤回する。次の確認ではデフォルトルートかフルルートテーブルの有無を見る。どちらもなければサーバーのプレフィックスを撤回する。個別処理の自動化が失敗した場合に備え、コアサイトからはカバーするプレフィックスを広告し続ける。

さらに各DNSインスタンスからAtlasアンカーへメッセージを送り、どれだけのアンカーが受け取ったかを数える。割合が低ければ、インスタンスの戻り経路に問題がある可能性を見てサービスプレフィックスを撤回する。以前は復旧後の再広告に人手が必要だったが、現在は撤回も再広告も自動だ。

ここに共通障害の保護が加わる。多数のインスタンスや複数の地点で低い値が同時に出たら、システムはその状態を疑わしいとみなし、直前の結果を保持する。試験では、ファイアウォールの変更ミスが測定値の収集を止めた。全インスタンスで到達率が0％になったが、プレフィックスは広告されたままだった。RIPE NCCはこれを想定どおりの動作として報告した。

RIPE NCCのDNSページによると、AuthDNSは逆引きDNSやripe.net、e164.arpaなどを提供するanycastサービスだ。クラスターの広告はAS197000からの193.0.9.0/24と2001:67c:e0::/48。BGPで撤回すれば、以前広告した経路を利用可能として扱わないようピアに知らせる。一方、コアサイトからのカバー経路も残る。利用者のリゾルバーが実際にどの道を選んだかは、この説明からは分からない。

公開された説明には、アンカー数、撤回と回復のしきい値、保持時間、ファイアウォール試験で対象になった正確な経路がない。そこが分かれば、運用者は同じガードを自分の環境で再現できるか判断しやすい。

この設計は二つの誤りに備える。孤立した低い値を信じすぎれば、まだ使える経路を撤回する。多数のゼロを信じなさすぎれば、本当の障害時にも古い経路を残す。重要なのは「自動化した」ことではなく、測定系の異常とサービスの異常を同じ入力として処理しないことだ。

出典