定期DNSヘルスチェックの設定方法

1回限りのDNS検索で分かるのは、現在の状態です。定期的に繰り返す検索なら、その状態が変化しているかどうかが分かります。そして、変更を予定していないドメインに起きた変化は、数週間後に発覚するより、すばやく知るべきことであるのがふつうです。

対象に含めるものを決める

気づかないまま変更されると実際に困るものから始めましょう。本番のドメインと主要なサブドメイン、メールの到達性に関わるドメイン、セキュリティのウォッチリストに載っているものなどです。変更があっても誰も対応しないドメインのチェックを予約しても、ほとんど意味がありません。目標は、実際に対応できるシグナルを得ることであり、誰も読まない網羅的なログを作ることではありません。

頻度を選ぶ

結果をどう活用するか

ジョブ自体は、価値の半分にすぎません。もう半分は、実行結果が前回と異なっていたときに何が起きるかです。最低限、連続する実行を比較できるだけの履歴を保持してください（このツールがジョブの実行履歴を、設定可能な保持期間にわたって保存しているのは、まさにこのためです）。各実行の結果をCSVやJSONでエクスポートすれば、その日に見るかどうか分からないダッシュボードで、誰かが目視で変化に気づくのを当てにするのではなく、プログラムで差分を取れます。

スケジュールが安定して動くようになると、実際的な効果として、DNSの監視が、ときどき行う手作業から、確認すべきことがあるときだけ注意を求めるバックグラウンドのプロセスに変わります。それこそが目的です。

チェックだけでなく、アラートも設計する

新しい発見がなかった実行も含め、実行のたびに通知するスケジュールチェックは、数週間もすれば、誰も見なくなってしまいます。それでは目的が丸ごと失われます。有用なシグナルは、あくまで変化です。今回の解決済みアドレスが前回と異なる、ドメインが解決成功から失敗に変わった（またはその逆）、到達できてはならない範囲に新しいアドレスが現れた、といったことです。「今日の結果はこちら」ではなく「前回から何が変わったか」を軸に通知を作れば、数か月後でも開く価値のあるアラートであり続け、受信トレイにたまる既読にならないラベルの1つになってしまうことを防げます。

チェック自体が失敗したらどうなるか

スケジュールされたジョブには、見つけたものへの対応だけでなく、自分自身が失敗したときの計画も必要です。ジョブがまったく実行できなくなった場合（キューが詰まった、ワーカープロセスがクラッシュした、依存するインフラが停止した）、それは個々のドメインの結果よりも優先度の高い、別種のシグナルです。安全網そのものが、誰にも気づかれないまま静かになってしまったことを意味するからです。「想定した時間枠内にジョブが実行されたか」を確認するシンプルで独立したチェックを設け、実行が遅れたらアラートを出せば、この穴を塞げます。そうしないと、黙って監視をやめてしまう監視システムは、すべてがまだ見張られているという誤った安心感を生むため、監視がまったくない状態よりもむしろ悪いと言えます。