DNS監視完全ガイド：ダウンタイムを防止し、障害を検知する手法

アプリケーションがオフラインになると、エンジニアリングチームはAPMダッシュボードに駆け込みます。CPUチャート、データベースの接続プール、ログを確認します。多くの場合、何も問題は見つかりません。サーバーは完全に健全なのに、顧客からは「サイトにアクセスできない」というメッセージが殺到します。

見えない依存関係：稼働率メトリクスが嘘をつく理由

この現象（しばしば「内側からの盲目」と呼ばれます）は、内部の監視プローブがユーザーと同じ経路を辿らないために発生します。インターネットで最も重要で壊れやすいルーティング層であるドメインネームシステム（DNS）に対して、完全に盲目なのです。

DNSは、世界分散された最終一貫性を持つ巨大なデータベースとして機能するため、解決チェーンでの障害は「500 Internal Server Error」として記録されません。完全な沈黙として記録されます。

図のように、解決の旅はTCPハンドシェイクが始まる前に複数の外部依存関係を導入します：

• クライアント側のスタブリゾルバー（アグレッシブにキャッシュする）
• ISPが運営する再帰リゾルバー（例：Comcast、Vodafone）
• インターネットのルート（Root）およびトップレベルドメイン（TLD）インフラ
• あなたの設定した権威ネームサーバー

チェーンが壊れる場所

ルートレベルでの壊滅的なパニックは非常に稀ですが、ネットワークのエッジは頻繁に失敗します。最も一般的な障害は、設定ミスや連鎖的なタイムアウトから発生します：

• 古いキャッシュの罠

迅速なインフラ移行時、以前의 IPアドレスのTTLが24時間であった場合、インターネットの大部分はタイマーが切れるまで新しいネームサーバーへの問い合わせを拒否し、ユーザーをオフライン・ハードウェアに取り残します。

• スプリットブレイン（分裂）レコード

複数の権威冗長ネームサーバーを運用している場合、不完全なゾーン同期が断続的な失敗を引き起こす可能性があります。東京のユーザーは正しいIPを受け取る一方、ロンドンのユーザーは古いゾーンファイルを提供するサーバーに到達するかもしれません。

SRE対応プレイブック

DNSの低下が疑われる場合、ブラウザキャッシュを無視して真実のソースに問い合わせる必要があります。標準の'dig'ではなく、ネームサーバー間のシリアル番号を明示的に確認して、スプリットブレインの同期問題を検出できます：

host -t SOA yourdomain.com ns1.yourprovider.com
host -t SOA yourdomain.com ns2.yourprovider.com

もし返されたシリアル番号が完全に一致しない場合、ネームサーバーは同期しておらず、異なる地域に異なる現実を提供しています。

成熟したオブザーバビリティ姿勢の設計

pingベースの稼働確認を、包括的な外部監視に置き換えることは、本番ワークロードにとって必須です。

強固な姿勢には、外側から内側への解決経路のテストが必要です。監視プローブは以下の条件を満たす必要があります：

• 複数の地理的POPから、非キャッシュの生（raw）クエリを実行する。
• 返された IP アドレスが、期待される ASN に厳密に一致することを検証する。
• P99の解決遅延にアラートを設定する。遅いDNSは遅いバックエンドと区別がつきません。

結論

運用のレジリエンス（回復力）とは、コンピューティングのオートスケーリングだけでなく、顧客が確実にそのコンピューティングに到達できることです。私たちはこの可視性のギャップを埋めるために、Heimdall Observer を設計しました。