Dotcom-Monitor ユーザーは、監視タスクに対して DNS 解決を実行する方法を広範囲に制御できます。 広範なユーザーからのフィードバックに基づいて、ホスト名を解決するための 4 つの異なる DNS オプションを監視タスクに使用できます。
デバイスキャッシュ
デバイスキャッシュはデフォルトのオプションで、以前のタスク(デバイスキャッシュ)の監視中に取得されたキャッシュネームサーバ(NS)アドレスが、最初は監視に使用されることを意味します。 デバイス キャッシュに必要なアドレスがない場合は、ルート DNS サーバーからのアドレスの自動照会が行われます。 このオプションを設定すると、Dotcom-Monitor はデバイス チェックのインスタンスごとに 1 回、ホスト名を解決します。 したがって、同じデバイス内の 1 つ以上のタスクに同じホスト名への参照がある場合、DNS ルックアップは 1 回だけ実行され、そのデバイスのチェックインの間はキャッシュされます。
ほとんどのチェックは非常に迅速で、1分以内に実行されるため、数秒ごとに同じホストを解決する理由はありません。 このオプションの欠点は、同じデバイス内のタスクごとにパフォーマンス データが異なる可能性があることです。 同じホスト上にある同じデバイス内の 2 つの URL を監視する場合、最初の URL には DNS 参照時間が含まれ、2 番目の URL はキャッシュされた DNS IP アドレスを使用し、DNS 解決が非常に高速になるため、常に低速になります。
この種類のキャッシュは、同一の DNS 解決モードを持つタスクに対してのみ一般的です。
キャッシュなし
キャッシュされないということは、デバイスキャッシュ(先行タスクのキャッシュ)が使用されないことを意味するため、新しい実行ごとに、DNSルートサーバーへの個別の照会が必要になります。 このオプションは、DNS ルックアップが毎回実行されるため、一定の時間を確保するのに便利です。 ただし、非キャッシュ オプションを使用すると、DNS サーバーの負荷が大幅に増加し、タスクの監視にかかる応答時間が長くなります。
このオプションは、ブラウザベースのBrowserViewまたはUserView監視プラットフォームでは、数百回のチェックで同じホスト名を何百回も解決することは現実的ではないため、使用できません。 たとえば、同じサーバー上に多数の要素を持つ Web ページの場合、ルート サーバーとは別の DNS 解決を行っているとします。 このようなシナリオでは、1 つのチェックにつき 1 回の解決で十分です。
TTL キャッシュ
TTL Cached は、前のタスク(デバイス キャッシュ)のモニタリング中に形成された NS キャッシュが、最初は監視に使用されることを意味します。 デバイス キャッシュに必要なアドレスがない場合は、 ローカル DNS サーバーからアドレスの自動照会が行われます。 このオプションは、実際のユーザーのエクスペリエンスを最もよく模倣します。
TTL オプションが設定され、指定した DNS サーバーに障害が発生した場合、TTL の有効期限が切れるまでは、Dotcom-Monitor が障害を検出しないことがあります (数日または数週間かかる場合があります)。 このオプションは、DNS 解決が適切に行えない監視が優先されない場合にのみ推奨されます。
この種類のキャッシュは、同一の DNS 解決モードを持つタスクに対してのみ一般的です。
外部 DNS サーバー
外部 DNS サーバーは、指定された IP アドレスが DNS サーバー アドレスと見なされ、NS データをポーリングすることを意味します。 これは、たとえば、ほとんどのクライアントが Google (8.8.8、8.8.4)や Cloudflare (1.1.1.1) などのパブリック キャッシュ サービスを使用している場合などに役立ちます。 この場合、DNS サーバーを Google の IP の 1 つに設定できます。 指定された Google DNS が有効な応答を提供している限り、ドメインを担当する DNS サーバーが正常に動作しない場合でも、Dotcom-Monitor は DNS エラーを検出しません。
名前解決を担当するサーバーを知っていて、DNS チェーンの解決全体を気にしていない場合は、もう 1 つの状況が発生します。 この場合、DNS 解決に使用する DNS サーバーを指定できます。 Dotcom-Monitor はルート サーバーからルックアップを伝達する必要がないため、適切な DNS サーバーに直接移動できるため、このオプションを使用すると DNS 解決時間も短縮されます。 ただし、このオプションでは、DNS 関連の問題がすべて検出されるわけではありません。
各アドレスは異なるキャッシュを作成します。 したがって、たとえば、1 つのデバイスの下にある 2 つのタスクが異なる外部 DNS (異なる IP) を持つ場合、2 つの異なるキャッシュが存在します。
-
DNS 監視の基本
DNS は何を表すのでしょうか。
要求されたホストの IP アドレスに関する情報は、インターネット上の任意の要求に対する応答を受信するための前提条件であるため、ドメイン ネーム システムは、最新のインターネット環境の基本的なテクノロジの 1 つです。 IPアドレス自体は「100.123.145.167」のような数値で、平均的なインターネットユーザーにとっては暗記が難しい。 インターネット上のすべての IP アドレスは、一意の数値です。 インターネット上のホストの IP アドレスは、複雑な構造に加えて、常に安定しているわけではないため、ホストの変更時などに変更できます。 このように、平均的なインターネット ユーザーにとってネットワーク アドレスをより快適に使用できるように、ドメイン ネーム システム (DNS) が導入されました。 人間は、数字のIPアドレスを使用する代わりに、アルファベットのドメイン名を使用して、インターネットに接続されたリソース(コンピュータ、Webサーバー、その他のデバイス)にアクセスします。
DNS は、クライアントが要求したシンボリック ドメイン名を、このドメイン ゾーンを提供するサーバーの IP アドレスに変換します。 DNS は、DNS サーバーという専用ホストを利用して、リソースのレコードを格納し、DNS 要求を処理します。 DNS サーバーは、その担当領域に関連するネットワーク アドレスを個別に解決したり、DNS 参照チェーンに沿って DNS サーバーにサービスを提供しないゾーンの要求を転送したりできます。
クライアントの DNS クエリを満たすためにクライアント (ブラウザーなど) から他の DNS サーバーに DNS 要求を渡す役割を担う DNS サーバーは、DNS リカーソルまたは DNS 再帰サーバーと呼ばれます。 DNS クエリは通常、DNS リカーソルから開始します。 一般に、ISP の DNS サーバーは DNS 再帰リゾルバーとして機能します。
DNS リソース レコードを格納し、要求を他の DNS サーバーにリダイレクトせずにクライアントに必要な IP アドレスを返すことができる DNS サーバーは、権限のある DNS サーバーと呼ばれます。 権限のある DNS サーバーは、通常、DNS 参照チェーンの最後にあるサーバーです。
DNS 再帰リゾルバーと権限のある DNS サーバーに加えて、DNS 参照プロセスに関与する中間サーバーには、より具体的な場所に DNS 要求を送信するルート ネームサーバーと、ホスト名の最後の部分を提供するトップレベルドメイン サーバー (たとえば、.com、.uk など) の 2 種類があります。
Web ブラウザでの DNS 解決のしくみ
ブラウザで URL を入力すると、ブラウザはインターネット サービス プロバイダ (ISP) の DNS サーバーを使用して、要求された Web サイトをホストするサーバーの IP アドレスを検索します。 これらの DNS サーバーのアドレスは、通常、接続時にホスティング プロバイダーによって送信されるか、IP 接続パラメーターで手動で指定する必要があります。 つまり、google.com などのドメイン名をブラウザのアドレス バーに入力すると、インターネット接続用に自動的にインストールされるローカル DNS サーバー、またはインターネット接続に指定したローカル DNS サーバーに対してリゾルバー要求が生成されます。
要求を受信すると、ローカル DNS サーバーは、ドメインと IP アドレスのマッピングに関する情報をキャッシュ内で検索し、必要な IP アドレスが見つからない場合は、現在使用可能なルート DNS サーバーの 1 つに要求が渡されます。 簡単に言うと、ローカル サーバーはキャッシュに必要な情報を持っていない可能性がありますが、他の DNS サーバーと通信できます。
ブラウザが応答を待っている間、ローカル DNS サーバーは世界のメイン サーバー (ルート DNS サーバー) にアクセスし、google.com の IP アドレスを要求します。ルート DNS サーバーは、ドメイン ゾーンの DNS サーバーに関する参照情報のみを格納します。したがって、ルート DNS サーバーは要求されたドメインの IP アドレスを認識しませんが、要求されたドメインのゾーン内のすべてのドメインを担当する DNS サーバーの IP アドレスを格納 google.com、これらは.com ドメイン ゾーンの DNS サーバーです。
ローカル DNS サーバーは、これらの DNS サーバーの IP アドレスを受け取り、そのサーバー上で要求された IP を検索しようとします。 この DNS サーバーは、Google の IP アドレスも認識しませんが、google.com の参照情報は、NS レコードでこのドメインに登録されている権限のある DNS サーバーによってホストされていることを認識しています。
ローカル DNS サーバーは、.com ドメイン内のこれらの DNS サーバーの IP アドレスを受け取り、権限のある DNS サーバーに DNS 要求を渡します。この権限を持つ DNS サーバーは、目的の IP アドレスを格納し、ローカル DNS サーバーに送信します。
ローカル DNS サーバーは、正しい IP アドレスを受信し、要求されたホスト名の IP アドレスをブラウザーに渡します。
ブラウザは、google.com IPアドレスを取得し、そのサーバーに直接接続し、ウェブサイトをロードします。
一般に、DNS 参照プロセスは非常に高速なので、DNS 参照チェーン全体がポーリングされたかどうかがユーザーに気付かない場合があります。
監視する DNS エラー
前述したように、DNS サーバーは、再帰クエリの実行中に他の DNS サーバーに順次クエリを実行し、応答に含まれる情報を一時的にキャッシュ メモリに格納できます。 この場合、DNS サーバーはドメインの IP アドレスを再要求する必要はありません。 このような情報をキャッシュに格納する最大許容時間は、リソース レコードの TTL フィールドで指定されます。 DNS キャッシュは、ハッカーがトラフィックをハッカーの Web サイトにリダイレクトするために使用する脆弱性の 1 つです。 この種の詐欺は、DNS サーバーのキャッシュ内の IP アドレスのスプーフィングを伴う DNS キャッシュ ポイズニングと呼ばれます。
また、DNS トンネリング、DNS 増幅攻撃、DDoS 攻撃、各種ハードウェア/ネットワーク障害などの DNS サーバー攻撃は、DNS の停止を引き起こし、Web サービスのパフォーマンスに悪影響を及ぼす可能性があります。
ドットコムモニターによるDNSモニタリング
攻撃者が DNS 設定を変更した場合は、最初に通知を受ける必要があります。 Dotcom-Monitor は、DNS 設定を防御するための予防的な手段として使用できる DNS 監視ツールを提供します。 指定した IP アドレスにホスト名が解決されたことをシステムが検出した場合、または DNS 参照の実行中に他の問題が発生すると、エラーが生成され、指定した通知アドレスにアラート通知が送信されます。 そのため、ユーザーがフィッシングやマルウェアの Web サイトに駆り立たされる前に、脅威にすぐに対処できます。