すべてのモニターチェックは同じ方法で開始されます。ホームページ、APIレスポンス、SMTPバナーの最初のバイトが返される前に、モニタリングエージェントはホスト名をIPアドレスに変換しなければなりません。その最初のステップがDNS解決であり、その設定方法によって稼働時間の数値が実際に何を意味するかが変わります。
ほとんどのチームはモニターのDNS設定に触れることはありません。チェックをapi.example.comに向けて間隔を選択し、先に進みます。しかし、そのチェックの下にあるリゾルバの動作が、実際のユーザーの体験を測定しているのか、数秒以内にDNS障害をキャッチしているのか、または複数の実行間で比較可能なクリーンな応答時間を生み出しているのかを決定します。これらすべてを同時に最適化することはできません。
Dotcom-Monitorではこの理由から、4つのDNS解決モードを提供しています。このガイドでは、それぞれを解説し、多くの人が誤解しがちなキャッシュあり、キャッシュなし、一時（TTLベース）キャッシュの選択に特に焦点を当てています。
なぜDNS解決がすべてのチェックで最初に実行されるのか
DNSはほぼすべての監視対象プロトコルの最初のホップです。ウェブサイトチェック、APIモニタリング呼び出し、メールサーバーモニタリングプローブ、ICMP pingモニタリングテストなど、各プロトコルは接続を開く前にIPアドレスが必要です。したがって、エージェントは最初にホスト名を解決し、その後TCP、TLS、アプリケーション層リクエストを実行します。
この順序は2つの理由で重要です。まず、DNSルックアップ時間は合計応答時間の一部であるため、遅いリゾルバはすべての数値を膨らませます。次に、DNS障害はチェック開始前に停止させます。解決に失敗すると、テストする接続も検証する証明書も、読み取るステータスコードもありません。モニターは重大な失敗を報告し、問題の根本原因は監視していた層より一つ下にあります。
DNSはすべての前に位置するため、そのルックアップをエージェントがどのように処理するかは単なる詳細ではなく重要な設計決定です。リクエストごとに新たに解決すればリゾルバ問題をすぐに検出できますが、各実行に負荷とルックアップ時間が追加されます。キャッシュを使うと数値は速く安定しますが、壊れたDNSレコードが数時間キャッシュに隠れる可能性があります。Dotcom-Monitorのモードは、実際に監視している対象に合ったトレードオフを選べるように設計されています。最初のホップを短縮する詳細については、DNS解決時間の改善ガイドをご覧ください。
Dotcom-Monitorの4つのDNSモード
Dotcom-Monitorでは監視タスクに4つのDNS解決モードを提供しています。それぞれがIPアドレスの取得元と保持期間を変えます。
デバイスキャッシュ
デバイスキャッシュはデフォルト設定です。1つのデバイスチェック内でエージェントは各ホスト名を1回解決し、チェックの残りの間その答えをすべてのタスクで共有します。チェック内で先に実行されたタスクがすでにホストを解決していれば、後のタスクはキャッシュされたIPを再利用します。そうでなければ完全なルックアップを行い、結果をチェック期間中キャッシュします。
利点は効率性です。ほとんどのチェックは1分未満で終了するため、数秒ごとに同じホストを解決する必要はありません。注意点はタスクごとのタイミングです。1つのデバイスで同じホストの異なるURLを監視している場合、最初のURLがDNSルックアップ時間を負担し、2つめはキャッシュされたIPを使用するので、2つめの方が速く見えますが実際は変わりありません。これはバグではなく予想される挙動ですが、ウォーターフォールを初めて見る人には驚きです。
非キャッシュ
非キャッシュはデバイスキャッシュを完全にスキップします。すべてのタスク実行は独自の完全なDNSルックアップを行うため、別の実行の答えを借りることはありません。これにより均一で比較可能なタイミングが得られ、すべてのチェックで同じ完全な解決コストを支払います。
トレードオフは負荷とレイテンシーです。毎回新鮮なルックアップをするため各タスクに時間が追加され、DNSインフラにより多くのトラフィックをかけます。また、非キャッシュモードはブラウザベースのBrowserViewやUserViewプラットフォームでは利用できません。リアルなページは同じホストから数十もの要素を取得するため、数秒で何百回もホスト名を解決するのはブラウザの動作とは異なり、1実行あたり1回の解決が現実的なモデルです。
TTLキャッシュ
TTLキャッシュはユーザーのマシンの本物のリゾルバの動作に似ています。レコードのTTL（存続期間）を尊重し、解決済みアドレスをキャッシュしてTTLが切れるまではそれを使用し、TTL切れ後はローカルDNSサーバーを通して再解決します。これはブラウザとOSが同じようにキャッシュするため、実際の訪問者の体験を最も忠実に模倣しています。
しかし同じ動作ゆえのリスクもあります。DNSサーバーが故障しても有効なキャッシュが残っている間は監視はそれに気づかない可能性があり、TTLは数時間、数日、またはそれ以上に設定されることがあります。したがって、リアルなユーザー体験の時間を求める場合には適切な選択ですが、DNS障害を迅速に検知することが重要な場合には不適切です。
外部DNSサーバー
外部DNSサーバーは指定したリゾルバIPでルックアップを行います。ユーザーの多くがGoogle（8.8.8.8、8.8.4.4）やCloudflare（1.1.1.1）といったパブリックリゾルバを利用している場合、そのサービスを通じた解決をテストできます。また、ゾーンに権威を持つリゾルバを指定すれば、再帰的なルックアップをスキップし、より速く直接的な解決が可能です。
制限はカバレッジです。選択したリゾルバが有効な答えを返す限り、モニターは成功とみなしますが、実際にドメインを担当するDNSサーバーが問題を起こしていても検出できません。したがって、このモードは特定のリゾルバの視点をテストしているに過ぎず、全チェーンをテストしているわけではありません。もう1つのポイント：異なるリゾルバIPごとにキャッシュは別々で、異なる外部サーバーを指した2つのタスクはそれぞれ独立したキャッシュを保持します。
キャッシュ形式の比較：キャッシュあり vs キャッシュなし vs 一時キャッシュ
この選択は人を迷わせるため、3つを並べて説明します。キャッシュ（デバイスキャッシュ）は効率性を最適化し、キャッシュなし（非キャッシュ）は均一で再現可能なタイミングと早期障害検知を最適化し、一時的キャッシュ（TTLキャッシュ）はブラウザのレコード期限切れと同様に更新を反映しリアリティを最適化します。
| モード | 解決方法 | 推奨用途 | 主なトレードオフ |
|---|---|---|---|
| デバイスキャッシュ（キャッシュ） | デバイスチェックごとに1回解決し、そのタスク間で共有 | 効率的なチェック；同一ホストの複数タスク | 最初のタスクがルックアップ時間を負担；後からのタスクが速く見える |
| 非キャッシュ（キャッシュなし） | 実行ごとに新たに完全解決 | 均一なタイミング；DNS問題の迅速検知 | DNS負荷増大・遅延増加；BrowserView/UserView非対応 |
| TTLキャッシュ（一時キャッシュ） | レコードTTLを尊重し、期限切れ後再解決 | 実際のユーザー体験の再現 | DNSサーバー障害がTTL終了まで隠れる可能性あり |
| 外部DNSサーバー | 指定したリゾルバIPをクエリ | 特定のパブリックまたは権威あるリゾルバのテスト | そのリゾルバの応答のみを確認、チェーン全体は非カバー |
要約：スピードを求めるならキャッシュ。障害を迅速に検知したいならキャッシュを使わず。ユーザー体験通りにしたいならTTLを尊重。各チェックの目的に合うモードを選んでください。
多くの監視ツールがDNS問題を見逃す理由
この設定をする価値があるのはここです。ほとんどの監視ツールは選択肢を与えません。一度ホスト名を解決しキャッシュし、そのレコードが有効な限り答えを再利用します。これで動作するのは本番でDNS問題（レコード誤り、権威サーバー障害、誤ったIPを返すリゾルバなど）が発生しない場合だけです。キャッシュされたモニターは古い答えに基づいて正常を報告し、実際のユーザーは障害に遭遇します。
解決モードの細かい制御は監視分野では稀です。毎回新鮮なルックアップを強制したり、TTL経過でレコードを古くしたり、特定のリゾルバを指定することはDotcom-Monitorの特徴であり、DNSが正常と仮定するモニターと実際にテストするモニターの境界線でもあります。DNS問題の検知がチェックの目的なら、ほとんどのツールのデフォルト「すべてキャッシュ」設定こそが問題を隠す原因です。
正しいDNSモードの選び方
望むモードはモニターが答える質問によります。DevOpsやSREチームでよく見られるパターンは次の通りです。
DNS障害をできるだけ早く検知したい。 非キャッシュを使います。解決に失敗するとすぐにアラートを出すチェックでは、レジストラの誤設定、期限切れゾーン、レコードの乗っ取りなど、古い答えがキャッシュに残っていては意味がありません。毎回新鮮に解決することで次回チェックで障害を検知できます。これに厳密なアラート設定を組み合わせてオンコールの担当者に通知しましょう。
実際の訪問者と同じタイミングを求めている。 TTLキャッシュを使います。SLAを支える稼働率監視や実ユーザー体験ダッシュボードでは、ブラウザの解決動作を模したほうが数値の正確性が保たれます。DNS障害検知の遅れが気になる場合は別に非キャッシュのチェックを用意してください。
同じホストに対して複数タスクを実行している。 デフォルトのデバイスキャッシュが普通は適切です。DNS負荷を抑えつつ1ラン内で1回の解決で済みます。タスクごとのウォーターフォール図を閲覧するときはキャッシュの動作を理解して、最初のタスクが解決時間を負担していると見なしてください。
特定のリゾルバを確認したい。 外部DNSサーバーモードを使用します。GoogleやCloudflareのパブリックリゾルバが正しいレコードを返すか検証したり、直接権威サーバーの動作をチェックしたりするときに適しています。ターゲットを絞ったテストなので、全体を把握するためにもっと広いチェックも併用すると良いでしょう。より広い戦略についてはDNS監視ツールのまとめも参考にしてください。
各モードで検知できるDNSエラー
DNSはよくある障害ポイントで、さまざまな原因で失敗します。移行時にレコードが変更されたり、ゾーンが期限切れになったり、権威サーバーがダウンしたり、最悪の場合は攻撃者がキャッシュを汚染してドメインを操作下のサーバーへ向けたりします。解決モードがこれらをどの速さで検知するかを決めます。
非キャッシュは常に新しい答えを得るため、解決問題を最速で表面化します。TTLキャッシュは古い有効キャッシュが障害を隠すため最も遅いです。外部DNSサーバーは指定したリゾルバの問題を検知しますが、チェーンの他の部分の問題は見つけられません。各階層でのチェックの障害内訳を知りたい場合はDNS、TCP、TLS、HTTPのエラーガイドをご覧ください。障害対策にはDNS障害回避のプレイブックと非キャッシュチェックの組み合わせも効果的です。
どのモードを使うにせよ、DNS監視のポイントは自分が設定していないIPへ名前解決が変わったことをいち早く察知することです。Dotcom-Monitorはホスト名が予期しないIPに解決された場合にエラーを生成しアラートを発信するので、ユーザーが間違ったサーバーに到達する前に対応できます。
Dotcom-MonitorでのDNSモード設定方法
解決モードの変更は監視タスクで数クリックでできます。デバイス種別によりラベルは多少異なりますが流れは同じです。
- ステップ1： Dotcom-Monitorプラットフォームで設定したいデバイスまたはタスクを開きます。
- ステップ2： タスク設定を編集し、DNS解決モード（またはDNSオプション）セクションを探します。
- ステップ3： 4つのモードからいずれかを選択します：デバイスキャッシュ、非キャッシュ、TTLキャッシュ、外部DNSサーバー。
- ステップ4： 外部DNSサーバーを選んだ場合は、問い合わせるリゾルバIP（例：8.8.8.8や1.1.1.1）を入力します。
- ステップ5： タスクを保存して複数回の間隔で実行し、応答時間の内訳を確認してDNSタイミングが期待通りかチェックします。
Dotcom-Monitorのグローバル監視ネットワークが各デバイスの実行元となるため、設定後は異なるロケーションからの解決挙動を比較できます。
まとめ
DNS解決はすべてのチェックで最初に行われるため、解決モードは自動任せにすべき設定ではありません。共有ホストに対して効率的にチェックしたいならキャッシュを使い、DNS障害検知が目的ならキャッシュなし、実ユーザと同じタイミングが欲しいならTTLを尊重し、特定サービスの視点をテストしたいなら外部リゾルバを指してください。
ほとんどのチームは複数のモードを使い分けることが多いです。単一のモニターであらゆる疑問に答えられることは稀だからです。チェックの目的に合わせてモードを選ぶことで、DNSに関する本当の実態が数値として見えてきます。
DNSを監視して稼働時間を守ろう
各チェックに合った解決モードを設定し、レコードの変更が起きた瞬間にアラートを受け取りましょう。Dotcom-Monitorはこのガイドが紹介するキャッシュ制御を備えたグローバルネットワークからDNS監視を実行しています。
