DNS 監視機能と機能の更新
ドメイン ネーム サーバー (DNS) システムは、インターネットの最も重要な構成要素の 1 つですが、誤解され、当然と思われることが多い。 DNSシステムは、ほとんど隠され、無視され、議論されていない家の基礎のようなものです。
しかし、基盤の問題がある家のように、DNSの問題が発生した場合、DNSシステムの上にすべて、またはDNSシステムに依存している場合、ネットワーク、接続性、ユーザーエクスペリエンスが影響を受けます。 したがって、DNS プロセスは監視の不可欠な部分であると考えています。 DNS プロセスが失敗した場合、ほとんどのユーザーは、消費されているオンライン リソースにアクセスできないためです。
デフォルトでは、Dotcom-Monitor は 、ルートサーバーから始まるホスト名を解決します。 ルート サーバーからホスト名を解決すると、チェック中に DNS チェーンが壊れ、ホスト名を適切な IP アドレスに解決できます。 ルート・サーバーからホスト名を解決すると、最も包括的なチェックが行われますが、一部のクライアントでは、特定の状況下で問題が発生する可能性があります。
ルート・サーバーからのホスト名の解決による問題のモニター
- 監視する合計時間の増加 – DNS 解決には数秒かかる可能性があるため、監視チェックの実行にかかる時間の合計が増加します。 場合によっては、特に監視インスタンスが高速 (HTTP ピクセルダウンロード) の場合、DNS 解決が監視の実行に要する合計時間の大半を占める場合があります。 そのため、監視には、Web サイトまたはオンライン リソースに関する平均的なユーザーの経験は反映されません。 したがって、クライアントが Web サイトの繰り返し訪問者エクスペリエンスの監視に関心を持っている場合、ルート サーバーからの DNS 伝播の監視は適切ではありません。
- DNS 解決は制御できないため、DNS の問題は無関係です – 場合によっては、DNS 解決プロセスがクライアントの制御下にないため、DNS の問題や停止を無視することを好みます。 DNS 解決の問題は、サービスへのエンド ユーザーのアクセスを禁止しているため、注意することが重要ですが、クライアントが制御できない DNS の問題に関する監視アラートやレポートを受信することは役に立ちません。
DNS 解決パフォーマンス チェックの制御
Dotcom-Monitor のユーザーは、監視タスクに対して DNS 解決を実行する方法を広範囲に制御できます。 広範なユーザーからのフィードバックに基づいて、ホスト名を解決するための 4 つの異なる DNS オプションを監視タスクに使用できます。
1. デバイスキャッシュ (デフォルトオプション) このオプションを設定すると、Dotcom-Monitor は、ホスト名を 1 つのインスタンスごとに 1 回解決します。 したがって、同じデバイス内の 1 つ以上のタスクに同じホスト名への参照がある場合、DNS ルックアップは 1 回だけ実行され、そのデバイスでのチェックの間はキャッシュされます。
ほとんどのチェックは非常に迅速で、1分以内に実行されるため、数秒ごとに同じホストを解決する理由がないと判断しました。 このオプションの欠点は、同じデバイス内のタスクごとにパフォーマンス データが異なる可能性があることです。 したがって、同じホスト上にある同じデバイス内の 2 つの URL を監視すると、最初の URL には DNS ルックアップ時間が含まれ、2 番目の URL はキャッシュされた DNS IP アドレスを使用し、DNS 解決が非常に高速になるため、常に低速になります。
2. 非キャッシュ – このオプションを設定すると、すべてのチェックでルートサーバーから伝播するホスト名が解決されます。 これは、DNS ルックアップが毎回実行されるため、一定の時間を確保するのに便利です。 ただし、非キャッシュ オプションを使用すると、DNS サーバーの負荷が大幅に増加し、タスクの監視にかかる応答時間が長くなります。
このオプションは、ブラウザベースのBrowserViewまたはUserView監視プラットフォームでは、数百回のチェックで同じホスト名を何百回も解決することは現実的ではないため、使用できません。 たとえば、同じサーバー上に多数の要素を持つ Web ページの場合、ルート サーバーとは別の DNS 解決を行っているとします。 このようなシナリオでは、1 つのチェックにつき 1 回の解決で十分です。
3. TTL Live – このオプションは、実際のユーザーのエクスペリエンスを最もよく模倣します。 Dotcom-Monitor はホスト名を一度解決し、監視場所に TTL (存続時間) 値をキャッシュします。 TTL 値は数秒から数週間に変化する場合があります。 TTL は、名前をホストする DNS サーバーによって制御されます。
TTL Live オプションが設定され、DNS サーバーに障害が発生した場合、TTL の有効期限が切れるまで(数日または数週間かかる場合があります)、Dotcom-Monitor が障害を検出しないことに注意してください。 このオプションは、DNS 解決が適切に行えない監視が優先されない場合にのみ推奨されます。
4. 特定の DNS サーバー – このオプションは、指定された DNS サーバーに対して、ホストを IP アドレスに解決するためにクエリを実行します。 これは、たとえば、ほとんどのクライアントが Google の 8.8.8.8 や 8.8.4.4 などのパブリック キャッシュ サービスを使用している場合などに役立ちます。 この場合、DNS サーバーを Google の IP の 1 つに設定できます。 指定された Google DNS が有効な応答を提供している限り、ドメインを担当する DNS サーバーが正常に動作しない場合でも、Dotcom-Monitor は DNS エラーを検出しません。
名前解決を担当するサーバーを知っていて、DNS チェーンの解決全体を気にしていない場合は、もう 1 つの状況が発生します。 この場合、DNS 解決に使用する DNS サーバーを指定できます。 Dotcom-Monitor はルート サーバーからルックアップを伝達する必要がないため、適切な DNS サーバーに直接移動できるため、このオプションを使用すると DNS 解決時間も短縮されます。 ただし、このオプションでは、DNS 関連の問題がすべて検出されるわけではありません。
[divider top=”no”]DNS 解決オプションを使用した特定の問題の解決
前述のように、各 DNS 解決オプションには長所と短所があります。 DNS 解決プロセスをカスタマイズする機能により、特定の状況やニーズに最適な柔軟性が得られます。 一般に、デフォルトのオプションである[デバイス キャッシュ]が推奨されます。 ただし、特定の状況下では、他の DNS 解決オプションは、特定の問題に対処するための有益なソリューションになる場合があります。
