デバイスとターゲットを作成する方法

仕組み

DNS サーバーの監視は、特定の IP アドレスを解決するために、指定された DNS サーバーに照会します。

ターゲットの作成

解決するホスト名

このフィールドでは、解決する URL を指定できます。 アドレスは、www.example.com などのブラウザで使用する場合とまったく同じ形式にする必要があります。 “http://” は含めないでください。

使用する DNS サーバー

特定の DNS サーバを照会するには、[カスタム( Custom )] オプション ボタンを選択し、ポーリングする DNS サーバの URL 名、IPv4 または IPv6 アドレスを入力します。 デフォルトでは、a.root-servers.net ルートサーバーを使用します。 カスタム DNS サーバーを指定しない場合、 letter.root-servers.net サーバー (“文字” は A から M までの文字) がランダムな順序でポーリングされます。

レコードの種類

照会する NS レコードの種類を選択します。

NS レコード・タイプの説明

  • A – ホスト名を IPv4 アドレスにマップする IPv4 アドレス レコード。
  • AAAA – ホスト名を IPv6 アドレスにマップする IPv6 アドレス・レコード。
  • 権限のあるネーム サーバーを委任するNS名サーバー レコード。
  • CNAME – 別の名前レコードの別名である正規名レコード。
  • SOA – 権限レコードの開始は、ドメイン、メール、およびレコードのタイミング情報に関する最も権限のある情報を戻します。
  • TXT – テキストレコードは、送信者ポリシー情報やその他のマシンで読み取り可能な情報だけでなく、一般的な情報にも使用できます。
  • MX – メール交換レコードは、ドメインのメッセージ転送エージェントを定義します。
  • PTR – ポインター レコードは、DNS 逆引き参照の正規レコードを指します。
  • SPF – 送信者ポリシーフレームワークは、現在では、TXT レコードで一般的に処理されるレガシ レコードです。
  • SRV – 特定のサービスのポートを指定します。
  • NAPTR – インターネット テレフォニー アドレス空間をインターネット アドレス空間にマップします。

レコードタイプはクエリの内容を定義するだけで、期待される応答がどのようになるかを自動的に定義するものではありません。 クエリに基づいて、[ 期待される応答 ] セクションで予想される応答を明示的に定義する必要があります。 さらに、[ 権限 リソース レコード] フィールドと [追加リソース レコード] フィールドを使用して、正確な構成に応じてクエリ応答を検証することもできます。

PTR が IP アドレスを逆にしました

PTR レコードの種類により、DNS 逆引き参照が発生します。 PTR レコードの種類を照会する場合、[解決するホスト名] には、以下で説明する形式の逆方向の IP アドレスが含まれている必要があります。

IPv4 の場合:

IP アドレスが 10.12.34.56 の場合

予想される応答は 56.34.12.10.in-addr.arpa です。

IPv6 の場合:

DNS 逆引き参照では、特別なドメイン “ip6.arpa” を使用します。

5.4.3.3.2.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b d.0.1.0.0.0.2.ip6.arpa.

ここで”5.4.3.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2″は逆のIPアドレスです。 2001:0db8::1:2345 は、元の反転なしです。

再帰が必要

このオプションを使用して、送信 DNS クエリで再帰希望 (RD) フラグを有効または無効にします。

  • いいえ – DNS クエリは RD フラグを送信しません。 選択したDNSサーバーが1ホップでターゲットを解決するかどうかを確認するために1回の反復を実行する場合に使用します。
  • はい – Dotcom-Monitor は、DNS サーバーが監視サービスの再帰を実行することを要求します (つまり、リモート サーバーは、必要な結果を検索するために監視サービスの DNS ツリーをスキャンします)。

Web ブラウザーなどのほとんどのアプリケーションでは、既定で RD フラグが有効になっているため、照会された DNS サーバーに有効な応答がない場合でも、DNS 解決が成功します。 この場合、照会された DNS サーバーは最上位の DNS サーバーに接続し、信頼できる結果を受信するまで結果のパスをたどります。

クライアント アプリケーション (インターネット ブラウザーなど) は、通常、RD フラグを使用します。

トラバーサル モード

必要なレコードの種類を持つ DNS 応答の解釈方法を定義します。

  • 完全再帰 – DNS ツリーのエンドリーフからの応答のみが、予想される応答について検証されます。 すべてのルート サーバーからの応答が必要な場合は、タイムアウトのルート サーバーからよりランダムな障害が発生します。 これは必ずしも停止を示しているわけではなく、1つ以上のルートサーバーに大きな負荷がかかっていて、時間内に応答しなかったことを示している可能性があります。
  • 最初の肯定的な回答で停止 – 指定されたレコードタイプの最初に見つかった応答のみがさらに分析されます。 必要なレコードの種類を持つ最初の応答は、DNS ツリーの末尾と見なされます。
  • 単一クエリ – 単一の DNS クエリから最初に受信した応答が、予想される応答について検証されます。

議定書

デフォルトでは、DNSルックアップにはUDPを使用し、DNSパケットサイズが UDP 制限の512バイトに達すると自動的に TCP に切り替わります。 [ プロトコル ] ボックスの一覧で必要なプロトコルを選択することで、DNS ルックアップに使用する必要があるプロトコルを明示的に設定できます。

時間検証のしきい値 (秒)

タスクが Web ページからの応答を待ってから、タスクを終了してエラーを返す秒数を入力します。 この値を空白のままにすると、タスクのデフォルトのタイムアウトは 120 秒です。

タイムアウトを無視 (サーバー タイムアウト フィルター)

複数のサーバーに対してクエリを実行する場合、1 つまたは複数のサーバーからタイムアウトを受け取るのが一般的です。 このフィルターを使用すると、このようなタイムアウトを無視するか、これらのタイムアウトのアラートを受信するかを指定できます。 オプションには、すべてのタイムアウトに関するアラート、正確なホストからのネットワークおよびタイムアウトエラーの除外、またはマスクに基づくノードの範囲が含まれます。

  • “*” – すべてのネットワーク関連エラーとタイムアウト エラーが含まれ、アラートがトリガーされます。
  • 空のフィールド – エンジンは、ネットワーク関連のエラーとタイムアウト エラーをすべて無視します。

マスクを追加すると、エンジンは、一致するホストまたは IP アドレスのネットワーク関連エラーおよびタイムアウト エラーをすべて無視します。

例

IPv4: 192.168.* は、192.168 で始まるすべてのアドレスをフィルタリングします。

IPv6: 2001:501:* は、2001:501 から始まる任意のアドレスをフィルタリングします。

url: len*a.ru は、”len” で始まり “a.ru” で終わるすべての URL をフィルタリングします。

複数のサーバーはセミコロンで除算されます。
2001:501:* ;レン*ラ・ル

期待される応答

[権限] オプションと [追加] オプションは、[DNS サーバー] フィールドでカスタム DNS サーバーが指定されている場合にのみ適用されることに注意してください (ルート サーバーや IP アドレスではありません)。

回答: 返された文字列の結果に、予想される回答フィールドに入力された値が含まれている場合、タスクは成功を返します。 論理式を使用して、より複雑な結果を定義できます。

例えば：

10.0.0.1 |127.0.0.1 |192.168.1.1

指定された IP アドレスのいずれかが返された文字列に含まれている場合、クエリは成功したと見なされます。

権限: 応答を解析して、権限セクションの値を取得します。

追加: 返される追加のリソース レコードを表示します。 リストに複数の DNS サーバーがある場合、これはかなりの数の結果を返す可能性があります。

複雑な構造の例

(answer[1].Name=tut.by | answer[2].Name=google.com) & !answer[1].Type=A & 'additional[2].Name=ns2.company.com' & key value | fftb

DNS オプション

NS アドレスの解決に使用するモードを決定します。 詳細については、「 DNS モード オプション」を参照してください。