Cisco Network Registrar ユーザ ガイド Software Release 6.2.1
DNS サーバ プロパティの管理
DNS サーバ プロパティの管理
発行日;2012/02/02 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 5MB) | フィードバック

目次

DNS サーバ プロパティの管理

DNS サーバの管理

DNS コマンドの実行

DNS サーバ ネットワーク インターフェイスの設定

DNS サーバ プロパティの設定

サーバの一般プロパティの設定

サーバのフォワーダの定義

サブゾーン転送の設定

解決例外の使用

キャッシング専用サーバの設定

委任専用ゾーンの指定

ルート ネームサーバの定義

再帰クエリーのイネーブル化

ラウンドロビンのイネーブル化

サブネットのソートのイネーブル化

差分ゾーン転送(IXFR)のイネーブル化

変更セットとチェックポイント処理

ゾーン クエリーの制限

NOTIFY のイネーブル化

サーバの詳細プロパティの設定

SOA 存続可能時間の設定

セカンダリ リフレッシュ時間の設定

セカンダリ リトライ時間の設定

セカンダリ有効期限の設定

グルー レコードの取り込み

不完全な委任のレポート

最大否定キャッシュ時間の設定

最大キャッシュ TTL の設定

最大メモリ キャッシュ サイズの設定

DNS キャッシュのフラッシュ

不良 Address レコードと他のキャッシュ アトリビュート

クエリー ソース アドレスおよびポート番号の設定

ローカル ポート番号と外部ポート番号の設定

DNS プロパティの調整

DNS サーバのトラブルシューティング

DNS サーバ プロパティの管理

この章では、DNS サーバ パラメータを設定する方法を説明します。この章で説明する操作を行う前に、プライマリ ゾーンとセカンダリ ゾーンの基本的なプロパティの設定方法を説明している、「ゾーンの管理」 をお読みください。

DNS サーバの管理

DNS サーバの管理では、安定度、統計、ログの表示、サーバの起動や停止、リロード、特定のコマンドの実行、およびサーバ アトリビュートの編集などを実行できます。

サーバの状態や安定度を表示し、サーバを停止、起動、およびリロードすることができます。ローカル クラスタ Web UI では、 DNS をクリックしてから DNS Server をクリックし、Manage DNS Server ページを開きます。

DNS コマンドの実行

Commands カラムの Run アイコン( )を使用して、DNS Server Commands ページを開くことにより、コマンドを使用します。各コマンドには独自の Run アイコンがあります(このアイコンをクリックし、完了したら Return をクリックします)。

Flush cache:「DNS キャッシュのフラッシュ」を参照してください。

Force all zone transfers:「ゾーン転送のイネーブル化」を参照してください。

Scavenge all zones:「ダイナミック レコードの清掃」を参照してください。

Remove non-authoritative RR set:「キャッシュ レコードの削除」を参照してください。


) サーバ エラーが見つかった場合は、サーバのログ ファイルに設定上のエラーがないかどうかを調べ、エラーを解決してから、このページに戻り、ページをリフレッシュします。


DNS サーバ ネットワーク インターフェイスの設定

ローカル クラスタで Web UI の Manage Servers ページから、DNS サーバのネットワーク インターフェイスを設定できます。このページに移動するには、 Servers をクリックしてから Manage Servers をクリックします。DNS サーバの Interfaces アイコン( )をクリックして、Manage DNS Server Network Interfaces ページを開きます。

このページには、サーバに対して設定できる利用可能なネットワーク インターフェイスが表示されます。デフォルトでは、サーバはすべてのネットワーク インターフェイスを使用します。インターフェイスを設定するには、そのインターフェイスの Configure カラムの Configure アイコン( )をクリックします。これによって、そのインターフェイスが Configured Interfaces テーブルに追加され、このテーブルで編集または削除できます。設定されたインターフェイスの名前をクリックすると、Edit DNS Server Network Interface ページが開きます。ここで、インターフェイスのアドレスおよびポートを変更できます。編集を終了したら、 Modify Interface をクリックしてから Return をクリックし、Manage Servers ページに戻ります。


) DNS の IPv6 機能は、DNS サーバが隔離され、スタンドアロンである(すべてのクエリーに対して独自のルートであり、権限を持つ)場合を除き、IPv4 インターフェイスの設定を要求します。


DNS サーバ プロパティの設定

ゾーンに対して設定したプロパティのほかに、DNS サーバ自体のプロパティを設定することができます。

サーバの一般プロパティの設定

サーバが属するクラスタまたはホスト マシンの名前など、DNS サーバの一般プロパティと、Network Registrar DNS サーバ ソフトウェアのバージョン番号を表示できます。DNS サーバの内部名は変更できます。その場合は、現在の名前を削除して新しい名前を入力します。この名前は表示上の名前であり、サーバの正式な名前は表していません。Network Registrar が正式な名前を参照したり DNS アップデートを行う場合、サーバの IP アドレスが使用されます(「DNS アップデートの設定」を参照)。


ステップ 1 ローカル クラスタ Web UI では、 DNS をクリックしてから DNS Server をクリックし、Manage DNS Server ページを開きます。

CLI では、DNS サーバのプロパティを表示するには、 dns [ show ] を使用します。

ステップ 2 サーバの名前をクリックして、Edit DNS Server ページを開きます。ページに、すべての DNS サーバ アトリビュートが表示されます。

ステップ 3 Modify Server をクリックして、DNS サーバ アトリビュートの変更を保存します。


 

サーバのフォワーダの定義

セキュリティのためにネットワーク トラフィックを制限する必要があるサイトは、1 つまたは複数のサーバを「フォワーダ」として指定し、ローカル サーバがインターネットにアクセスする前に、すべてのオフサイト要求をフォワーダによって処理することができます。そのうちにフォワーダは豊富なデータ キャッシュを蓄積して、ほとんどの要求を満足できるようになります。

フォワーダは次の場合に役に立ちます。

インターネット コネクション上の負荷を軽減する:フォワーダはキャッシュを構築するため、外部ネームサーバに送信される要求数が減り、DNS のパフォーマンスが向上します。

繰り返しのクエリーに対する DNS 応答を改善する:フォワーダは、キャッシュを利用することでほとんどのクエリーに回答できます。

ファイアウォールとして機能する:ルート ネームサーバにアクセスできないホストは、それが可能なフォワーダに要求を送信できます。


ヒント ネームサーバによるオフサイト サーバへのアクセス試行を禁止することで、ネームサーバに対する制約を一層厳しくします。この種類のサーバは、フォワーダだけを使用します。スレーブ サーバは、クエリーに対してその権限およびキャッシュ データから回答しますが、キャッシュにないデータについては完全にフォワーダに依存します。フォワーダが回答を提供しない場合、スレーブ モード サーバは、その他のサーバへのアクセスを試行しません。


フォワーダは、複数構成することができます。デフォルトの 8 秒を経過しても最初のフォワーダが応答しない場合、Network Registrar は、次のフォワーダにクエリーを行います。この動作は、いずれかのフォワーダが応答するまで、またはリストの最後まで続けられます。回答が得られなかった場合、それ以降の DNS サーバの動作は、スレーブ モードがオンになっているかオフになっているかによって異なります。

スレーブ モードがオンになっている場合、DNS サーバは検索を中止し、回答が見つからないと応答します。

スレーブ モードがオフになっている場合、DNS サーバは、登録されているフォワーダがない場合と同様に、クエリーをドメインの指定ネームサーバに送信します。

DNS forward-retry-time アトリビュートによって、転送リトライ間隔のデフォルトの 8 秒を変更できます。これらのクエリーは再帰的であり、フォワーダによる解決により多くの時間がかかることがあるため、この間隔は、設定されるフォワーダまたは解決例外サーバの合計数から 1 を引いた数で request-expiration-time (デフォルトでは 90 秒)を割った値に設定します(「再帰クエリーのイネーブル化」も参照)。

ローカル クラスタ Web UI では、Edit DNS Server ページの Forwarders カテゴリの下で、転送サーバの IP アドレスを入力し、スレーブ モードをイネーブルにするかディセーブルにするかをクリックしてから、 Modify Server をクリックします。

CLI で次のように指定します。

フォワーダとして使用するネームサーバのアドレスを指定するには、 dns addForwarder を使用します。複数のアドレスを指定する場合は、アドレス間を空白で区切ります。

サーバをスレーブとして指定するには、 dns enable slave-mode を使用します。

現在のフォワーダをリストするには、 dns listForwarders を使用します。

フォワーダのリストを編集するには、不要なフォワーダを削除してから、入力し直す必要があります。

フォワーダまたはフォワーダのリストを削除するには、 dns removeForwarder を使用します。


) サブゾーン転送(「サブゾーン転送の設定」を参照)および解決例外(「解決例外の使用」を参照)は、設定したフォワーダよりも優先されます。


サブゾーン転送の設定

ゾーンにフォワーダ セットがある場合(「サーバのフォワーダの定義」を参照)、通常の Network Registrar 動作ではサブゾーン ネームサーバに対する委任は無視され、クエリーがこれらの転送サーバに転送されます。通常は、サブゾーン サーバに解決例外を設定する必要があります(「解決例外の使用」の項を参照)。サブゾーンが大量にある場合、この設定は実用に向かない場合があります。subzone-forward アトリビュートを no-forward に設定して、サーバがそのサブゾーンのクエリーを受信した場合、関連するサブゾーン NS レコードが検索され、対応する IP アドレスが解決され、それらの IP アドレスにクエリーが委任されます。デフォルトでは、要求された場合にフォワーダを使用します。ただし、サブゾーン転送は、要求されたフォワーダを上書きします。

たとえば、no-forward オプションを設定した場合、example.com ゾーンとそのサブゾーン boston.example.com および chicago.example.com では、次のようになります。

nrcmd> zone example.com set subzone-forward=no-forward
 

クエリーはフォワーダに転送されませんが、その NS および対応する A レコードが検索されます。デフォルトは subzone-forward =normal で、クエリーは転送されます。

解決例外の使用

ドメイン外の特定の名前に関して、ルート ネームサーバへのクエリーという標準の名前解決方法を DNS サーバが使用しないように設定するには、「解決例外」を使用します。これは、ルート ネームサーバをバイパスし、名前解決を処理する特定のサーバを対象とします。

たとえば、example.com に、Red、Blue、Yellow、Green という 4 つの子会社があるとします。各子会社は、.com ドメインの下に各自のドメインを持っています。Red のユーザが Blue のリソースにアクセスしようとした場合、Red の DNS サーバは、Blue に対する権限がないので、ルート ネームサーバに要求を出します。このようなクエリーは、不必要なトラフィックを発生させるだけでなく、場合によっては失敗することがあります。これは、外部クエリーや、アドレスが一意でない到達不可能なプライベート ネットワークを使用するサイトから、内部リソースが保護されていることがあるためです。

解決例外は、この問題を解決します。Red の管理者は、ユーザがアクセスする可能性のある他のすべての example.com ドメインと、少なくとも 1 つの対応するネームサーバをリストに登録します。Red のユーザが Blue のサーバにアクセスする場合、Red サーバは、ルートを照会する代わりに、Blue サーバに尋ねます。


) サブゾーンに解決例外を設定すると、クエリーでは、解決例外サーバではなくサブゾーン NS レコードが使用されます。解決例外を定義しない場合、グローバル転送を設定すると(「サブゾーン転送の設定」を参照)、サブゾーンの委任のためのクエリーは、そのサブゾーンの権限サーバではなく、フォワーダに転送されます。ただし、ゾーンに対して subzone-forward アトリビュートを no-forward に設定すると、ゾーンのサーバが、すべてのサブゾーンの暗黙的な解決例外サーバとして設定され、転送や明示的に設定された解決例外がそのゾーンについて無視されます。サブゾーンに解決例外を定義するのは、特定のサブゾーンに対するクエリーがグローバル フォワーダに転送されるのを防ぐには効果的な方法ですが、同じことをゾーン内のすべてのサブゾーンに対して指定する場合は、サブゾーン転送を使用します。


ローカル クラスタ Web UI では、Edit DNS Server ページの Resolution Exceptions カテゴリの下で、想定される各ネームサーバのドメイン名と IP アドレスを入力し、 Modify Server をクリックします。例外リストを削除するには、削除するネームサーバのドメイン名と IP アドレスの横の Delete アイコン( )をクリックし、 Modify Server をクリックします。

CLI で次のように指定します。

例外ドメインとサーバを追加するには、 dns listExceptions および dns addException を使用します。複数追加する場合は、アドレス間を空白で区切ります。このコマンドは、ローカル権限ゾーンの外側の名前について、DNS サーバが標準の名前解決を使用しないようにする場合にだけ使用します。

解決例外を削除するには、 dns removeException を使用します。

解決例外を置き換えるには、 dns addException を新しい値とともに使用します。また、サーバがキャッシュにある古い解決の値を参照しないように、キャッシュをフラッシュする必要があります。

キャッシング専用サーバの設定

定義によると、すべてのサーバはキャッシング サーバです。これは、受信したデータの有効期限が切れるまでデータを保存するためです。ただし、任意のゾーンに対して権限を持たない「キャッシュ専用」サーバを作成できます。このタイプのサーバの唯一の機能は、権限サーバからのデータをメモリに格納してクエリーに回答することです。キャッシング専用サーバは、データを取得またはキャッシュして、後続のクエリーに回答できます。したがって、キャッシュ内のレコードに対する後続のクエリーでは、オーバーヘッド(レイテンシ)は大幅に低下します。

最初に Network Registrar をインストールした場合、ゾーンを設定しない限り、DNS サーバは自動的にキャッシング専用の非権限サーバになります。DNS サーバをそのままキャッシング専用サーバとして使用するには、キャッシング専用サーバの参照先としての、権限のあるプライマリまたはセカンダリ DNS サーバが必要です。キャッシング専用サーバは、いかなるゾーンに対しても、権限サーバとしてリストしないでください。

キャッシング専用サーバは再帰クエリーに応答するようにセットアップする必要があります。再帰クエリーとは、サーバが、アドレス解決データでキャッシュをアップデートするために権限サーバの取得を試行し続けることです。デフォルトでは、Network Registrar サーバは再帰的です。

キャッシング専用サーバのパフォーマンスを調整するには、次の操作を実行します。

mem-cache-size 値を設定し、オペレーティング システムの物理メモリ容量に適した最大許容値までメモリ内のキャッシュを増加します。

nrcmd> dns set mem-cache-size=200MB
 

大きなキャッシュを使用するときはキャッシュの固定をディセーブルにし、大きなキャッシュの保存が必要な場合に、リロード時間が問題にならないようにしてください。 persist-mem-cache アトリビュートをディセーブルにします。

nrcmd> dns disable persist-mem-cache
 

ただし、このアトリビュートをディセーブルにすると、サーバがリロードされるたびにキャッシュが破棄されることに注意してください。

restrict-query-acl アトリビュートを設定して、特定のクライアントだけにクエリーを制限します。

nrcmd> dns set restrict-query-acl=myaccesslist
 

ローカル クラスタ Web UI では、 DNS DNS Server 、サーバの名前の順にクリックして、Edit DNS Server ページを開きます。Forwarders カテゴリで、上記のアトリビュートを設定します。

CLI では、上にリストしたコマンドを使用します。

委任専用ゾーンの指定

指定されたゾーンに対するクエリーで、委託だけを期待するようにサーバに指示することができます。つまり、ゾーンには、サブゾーン委任などの NS レコードと、ゾーン頂点にある SOA レコードだけが含まれるように指示できます。その結果、無関係な委任解除(in-zone)データを持つ権限ネームサーバからの、「ワイルドカード」データまたは「合成」データをフィルタリングすることができます。そのためには、DNS サーバの delegation-only-domains アトリビュートをイネーブルにします。

ルート ネームサーバの定義

ルート ネームサーバは、すべての最上位レベルのドメインの権限ネーム サーバのアドレスを保持しています。新しくインストールした Network Registrar DNS サーバを初めて起動すると、Network Registrar DNS サーバは、現在のルート ネームサーバを要求するための権限として、あらかじめ設定されているルート サーバのセット(ルート ヒントと呼ばれます)を使用します。

このルート サーバのクエリーに対する応答を受け取ると、Network Registrar は、それをキャッシュに格納し、ルート ヒント リストを参照します。キャッシュの有効期限が切れると、サーバは上記のプロセスを繰り返します。Network Registrar は固定的キャッシュを持つので、再起動した場合でもこのデータを再度照会する必要はありません。現在の正式なルート サーバ レコードの TTL(存続可能時間)は 6 日間です。したがって、Max.Cache TTL 値を 6 日より短く指定しない限り、Network Registrar は、6 日ごとにクエリーを行います(「最大キャッシュ TTL の設定」を参照)。

設定済みのサーバはヒントとしてのみ使用するため、完全なセットである必要はありません。ルート サーバを定期的(毎月または半年ごと)に参照し、情報を変更または追加する必要があるかどうか確認する必要があります。

ローカル クラスタ Web UI では、Edit DNS Server ページの Root Nameservers カテゴリの下で、追加する各ルート ネームサーバのドメイン名と IP アドレスを入力し、 Modify Server をクリックします。

CLI では、 dns addRootHint を使用します(『 Cisco CNS Network Registrar CLI Reference Guide 』の dns コマンドに関するユーザ ガイドラインを参照してください)。

再帰クエリーのイネーブル化

クエリーには、「 再帰クエリー 」と「 反復クエリー (非再帰クエリー)」の 2 種類があります。DNS クライアントは通常、再帰クエリーを生成します。この場合、ネームサーバは、自分のキャッシュ内にないすべての非権限データを他の DNS サーバに問い合せます。反復クエリーの場合、ネームサーバがクエリーに回答するのは、当該ゾーンに対して権限がある場合、自分のキャッシュ内に回答がある場合、または次に問い合せるべきネームサーバをクライアントに教える場合です。通常、ルート サーバは、再帰ではなく、反復を行うように設定します。再帰は、「私がいったん Bob と話をして、それからあなたに伝えに戻ります」というイメージです。反復とは、「私が Bob と連絡が取れるようにしますから、情報についてはあなたが直接 Bob から聞いてください」というイメージです。

アクセス制御リスト(ACL)に対して restrict-recursion-acl アトリビュートを設定して、再帰クエリーが実行される発行元のクライアントを制限することもできます。「ゾーン クエリーの制限」を参照してください。

次に、再帰クエリーのパフォーマンスを最適化するために設定できるその他のアトリビュートのリストを示します。ただし、一般にこれらの値はデフォルトのままにします。

forward-retry-time :フォワーダまたは解決例外サーバに対してクエリーを転送するためのリトライ間隔(デフォルトは 8 秒)。「サーバのフォワーダの定義」を参照してください。

request-expiration-time :一般的な DNS クエリーの有効期限(デフォルトは 90 秒)。

request-retry-time :一般的な DNS クエリーのリトライ間隔(デフォルトは 4 秒)。

tcp-query-retry-time :切り詰められた UDP パケットに応答する TCP を通じた DNS クエリーのリトライ間隔(デフォルトは 10 秒)。

ラウンドロビンのイネーブル化

クエリーの結果、1 つのネームサーバに関して複数の A レコードが返される場合があります。ほとんどの DNS クライアントがリスト中の最初のレコードから使用し始め、および、最初のレコードしか使用しないということを補正するためには、「 ラウンドロビン 」をイネーブルにして負荷を共有します。この方法により、同じ名前を解決する一連のクライアントが、解決ベースで異なるアドレスに接続するようになります。DNS サーバは、クエリーのたびに、レコードの順序を再編成します。これは、ロード バランシングというよりも、サーバの実際の負荷に基づくロード シェアリングの方法です。


ヒント サーバの A レコードの TTL プロパティを使用して、ラウンドロビン サーバから別のサーバへと切り替わる頻度を調整できます。


ローカル クラスタの Web UI では、Edit DNS Server ページの Miscellaneous Options and Settings カテゴリの下で、 Enable round-robin アトリビュートをイネーブルに設定し、 Modify Server をクリックします。

CLI では、ラウンドロビン プロパティがイネーブル(デフォルト)かどうかを確認するには、 dns get round-robin を使用します。イネーブルでない場合は、 dns enable round-robin を使用します。

サブネットのソートのイネーブル化

BIND 4.9.7 で実装されているとおり、サブネットのソートをイネーブルにすると、Network Registrar DNS サーバは、クエリーに応答する前に、クライアントのネットワーク アドレスを確認します。クライアント、サーバ、およびクエリーのターゲットが、同じサブネット上にあり、ターゲットが複数の A レコードを持つ場合は、サーバは、ターゲットに最も近いアドレスを応答パケットの先頭に置いて、回答内で A レコードを並べ変えます。DNS サーバは常にターゲットのすべてのアドレスを返しますが、ほとんどのクライアントは、最初のアドレスを使用して残りを無視します。

クライアント、DNS サーバ、クエリーの宛先が同じサブネットに置かれている場合、Network Registrar はまず、ラウンドロビン ソートを適用し、次にサブネットのソートを適用します。その結果、ローカルの回答が 1 つの場合には、その回答がリストの一番上に留まり、複数のローカル A レコードがある場合には、サーバによってその順序が入れ替えられます。

ローカル クラスタの Web UI では、Edit DNS Server ページの Advanced Options and Settings カテゴリの下で Enable subnet sorting アトリビュートをイネーブルに設定し、 Modify Server をクリックします。

CLI では、 dns enable subnet-sorting または dns disable subnet-sorting (デフォルト)を使用します。

差分ゾーン転送(IXFR)のイネーブル化

差分ゾーン転送(IXFR、RFC 1995 にて規定)では、変更されたデータだけをサーバ間で転送できます。これは特に、ダイナミックな環境で役に立ちます。IXFR は、NOTIFY(「NOTIFY のイネーブル化」を参照)とともに機能することによって、より効率的なゾーン アップデートを保証します。

プライマリ ゾーン サーバでは、常に IXFR が提供されます。IXFR を明示的にイネーブルにすると、この機能がセカンダリ ゾーン サーバにも提供されるため、サーバにセカンダリ ゾーンが設定されている場合は、この機能をイネーブルにしても意味はありません。このグローバル設定とセカンダリ ゾーン設定の違いは、セカンダリ ゾーンに特定の設定がないときに、グローバル設定がデフォルト値として使用されることです。


ステップ 1 ローカル クラスタ Web UI では、Edit DNS Server ページの Zone Defaults カテゴリの下で、 Request incremental transfers (IXFR) アトリビュートをイネーブルに設定します。

ローカル クラスタ CLI では、 dns enable ixfr-enable を使用します。デフォルトでは、 ixfr-enable アトリビュートはイネーブルに設定されています(『 Network Registrar CLI Reference 』の dns コマンドを参照)。

ステップ 2 セカンダリ ゾーンでは、 Maximum IXFR-only interval (secondary zones) アトリビュートを設定することにより、差分ゾーン転送を細かく調整できます。これは、IXFR を実行する最長の間隔です。この間隔が経過すると、完全ゾーン転送(AXFR)が適用されます。通常は、24 時間または数日に設定します。

ステップ 3 Modify Server をクリックします。


 

変更セットとチェックポイント処理

Network Registrar は、権限データベース(auth.db)にコミットされる前に、RR データへの最新の変更を収集する変更セット データベースを維持します。DNS サーバは、次の項目に対する応答時または実行時に、auth.db をチェックする前に、まず変更セット データベースをチェックします。

外部 DNS アップデート

完全または差分ゾーン転送

ゾーン チェックポイント処理(この項の後半を参照してください)

古いレコードの清掃(「ダイナミック レコードの清掃」を参照)

差分または完全構成データベース リロード

単一の DNS 変更セットは、1 つ以上の RR から構成されることがあります。DNS サーバは、データベースのトランザクション ログにデータを定期的にフラッシュします。データは、auth.db にコミットされる前にこのデータベースに蓄積されます。変更セット データベースは、通常の mcdshadow バックアップ時にバックアップされます。

変更セット データベースが際限なく増大しないように、サーバは定期的にこのデータベースをトリムします。この結果、たとえば、DNS クライアントがトリムされた RR のシリアル番号に基づいてゾーン IXFR を要求した場合、その DNS サーバは IXFR を実行できませんが、完全ゾーン転送(AXFR)を実行する必要があります。

ゾーン チェックポイント処理では、DNS サーバが中断された場合に auth.db を再作成するために必要になることがあるゾーン データのスナップショットが作成されます。サーバは、定期的にチェックポイント ファイルを自動更新します。ゾーン チェックポイント処理は、特定の最低しきい値を超える各変更セットで発生し、それ以外にもデフォルトで 3 時間ごとに発生します。 checkpoint-interval DNS サーバまたはゾーン アトリビュートを使用して、1 ~ 168 時間の間でこの間隔を調整できます。

ローカル Web UI では、ゾーン チェックポイントを手作業で適用できます。List/Add Zones ページまたは List/Add Reverse Zones ページで Run アイコン( )をクリックします。次に、Zone Commands for Zone ページで、Checkpoint ゾーンの横の Run アイコン( )をクリックします。

CLI では、 zone name chkpt を使用するか、または zone name dumpchkpt を使用して、より人間に理解しやすい形でゾーン チェックポイント ファイルをダンプします。

ゾーン クエリーの制限

アクセス制御リスト(ACL)に基づいて、特定のゾーンだけにクライアントによるクエリーを制限できます。ACL には、ソース IP アドレス、ネットワーク アドレス、TSIG キー(「トランザクション セキュリティ」を参照)、またはその他の ACL が含まれることがあります。ゾーンの restrict-query-acl アトリビュートによって設定される ACL は、非権限ゾーンに対するクエリー用のフィルタとして機能します。つまり、クエリーの宛先が権限ゾーンの場合は、そのゾーンの ACL が適用されます。

これらのクライアントを含む ACL に対して restrict-recursion-acl アトリビュートを設定して、特定のクライアントだけからの再帰要求を実行するように、サーバを制限することもできます(「アクセス コントロール リスト」を参照)。 restrict-recursion-acl の設定を解除した場合、任意のクライアントが再帰クエリーを要求できます。

NOTIFY のイネーブル化

NOTIFY プロトコルは、RFC 1996 で説明されていて、Network Registrar DNS プライマリ サーバは、これを使用してゾーン変更が起こったことをセカンダリ サーバに通知します。NOTIFY パケットは変更そのものを示すのではなく、変更が発生したことを示すだけです。また、ゾーン転送要求をトリガーします。NOTIFY は、ネームスペースが比較的ダイナミックな環境内で使用します。

ゾーンのマスタ サーバは、転送先のセカンダリ サーバを具体的に知ることができないので、Network Registrar は、そのゾーンの NS レコードにリストされているすべてのネームサーバに通知します。唯一の例外は、SOA プライマリ マスタ フィールドに指定されているサーバです。

IXFR と NOTIFY は一緒に使用できますが、必ずしも一緒に使用する必要はありません。ゾーンの変化が激しく、すべてのセカンダリ サーバをすぐに更新しても NOTIFY トラフィックが一定になる保証がない場合に、そのゾーンの NOTIFY をディセーブルにすることができます。このようなゾーンでは、リフレッシュ時間を短くし、NOTIFY をディセーブルにする方が適切な場合があります。


ステップ 1 Edit DNS Server ページの Zone Defaults カテゴリの下で、 Send zone change notification (NOTIFY) アトリビュートをイネーブルに設定します。

ローカル クラスタ CLI では、 dns enable notify を使用します。NOTIFY は、デフォルトでイネーブルになっています。NOTIFY はゾーン レベルでイネーブルにすることもできます。ゾーン レベルで、NS レコードで指定されているサーバ以外のサーバを通知対象として指定するには、 zone name set notify-set に、カンマで区切られたサーバのリストを指定します。

ステップ 2 他の NOTIFY アトリビュートを必要に応じて設定します。

ステップ 3 Modify Server をクリックします。

ステップ 4 NS レコードで指定されているネームサーバ以外のネームサーバを追加するには、 Zones をクリックします。

ステップ 5 ゾーン名をクリックします。

ステップ 6 Edit Zone ページの notify-set アトリビュートにサーバを追加します。複数の場合はカンマで区切ります。

ステップ 7 notify アトリビュートを true に設定します。

ステップ 8 このページで Modify Zone をクリックします。


 

サーバの詳細プロパティの設定

次の詳細サーバ プロパティを設定することができます。

SOA およびセカンダリ サーバのアトリビュート

グルー レコードの事前取り込み

不完全な委任のレポート

緩和 DNS アップデートのイネーブル化

キャッシュ時間リミットおよびサイズの設定

ローカル ポート番号と外部ポート番号の設定

不良 A レコード クエリーの処理

デバッグの設定

SOA 存続可能時間の設定

SOA レコードの「存続可能時間(TTL)」は、通常、ゾーンのデフォルト TTL によって決まリます。ただし、SOA TTL を明示的に設定して、SOA レコード データをサーバがキャッシュに保持する最大秒数を設定できます。たとえば SOA TTL を 3600 秒(1 時間)に設定した場合、外部サーバは、1 時間が経過した後でキャッシュから SOA レコードを削除し、ネームサーバに再び照会する必要があります。

Network Registrar は、権限クエリーに対して明示的に TTL の値を回答します。明示的な TTL の値が存在しない場合、ゾーンに対してデフォルトの TTL が使用されます。この値は、 defttl ゾーン アトリビュートの値によって設定されます。リリース 3.5 より前のバージョンの Network Registrar で作成されたデータベースには、 defttl ゾーン アトリビュートがなく、ゾーンの SOA レコードにある最小 TTL がデフォルトの TTL として使用されます。

通常、Network Registrar は、明示的な TTL の値を持たない RR を使用したゾーン転送によって応答する場合、デフォルト TTL を前提とします。ゾーンのデフォルトの TTL の値を管理のために変更した場合、Network Registrarは、ゾーン転送を要求するすべてのセカンダリ DNS に対して、完全ゾーン転送を自動的に適用します。


ステップ 1 ローカル クラスタ Web UI では、Add Zone または Edit Zone ページで、Zone Default TTL を設定します。デフォルトは 24 時間です。

ローカル クラスタ CLI では、 zone name set defttl を使用します。

ステップ 2 必要に応じて、SOA レコードだけに対する TTL である SOA TTL を設定します。デフォルトは、Zone Default TTL 値です。

ステップ 3 ゾーンの NS レコードに対して明確に TTL 値を設定することもできます。アトリビュートの下にリストされている nsttl の値を設定します。この値のデフォルトも、Zone Default TTL 値です。

ステップ 4 Modify Zone をクリックします。

ステップ 5 サーバをリロードします。


 

セカンダリ リフレッシュ時間の設定

セカンダリ リフレッシュ時間は、セカンダリ サーバがプライマリ サーバに対して、ゾーン転送の必要性を問い合せる頻度を示します。適切な範囲は、1 時間から 1 日の間で、ゾーン データが変更される頻度に依存します。

NOTIFY を使用する場合は、プライマリ サーバ データに変更があるとセカンダリ サーバに通知されるので、転送間で長い遅延を発生させることなく、リフレッシュ時間を大きな値に設定できます。NOTIFY の詳細については、「NOTIFY のイネーブル化」を参照してください。

ローカル クラスタ Web UI では、Add Zone または Edit Zone ページで Secondary Refresh フィールドにリフレッシュ時間を設定します。デフォルトは 3 時間です。必要な変更を行ったら、 Modify Zone をクリックします。

CLI では、 zone name set refresh を使用します。デフォルトは 10800 秒(3 時間)です。

セカンダリ リトライ時間の設定

DNS サーバは、ゾーン転送が連続して失敗したときにセカンダリ リトライ時間を使用します。リフレッシュ間隔が経過し、ゾーン転送のポーリング試行が失敗すると、サーバは、成功するまで続けて再試行を試みます。適切な値は、リフレッシュ時間の 3 分の 1 から 10 分の 1 までです。デフォルトは 1 時間です。

ローカル クラスタ Web UI では、Add Zone または Edit Zone ページで Secondary Retry フィールドにリトライ時間を設定します。デフォルトは 1 時間です。必要な変更を行ったら、 Modify Zone をクリックします。

CLI では、 zone name set retry を使用します。

セカンダリ有効期限の設定

セカンダリ有効期限は、セカンダリ サーバがゾーン転送時にゾーン アップデートの受信に失敗した後でクエリーに応答するときに、ゾーン データに対する権限を主張できる最長時間です。この値には、プライマリ サーバに長期の障害が発生しても対応できるように、大きな値を設定します。デフォルトは 7 日間です。

ローカル クラスタ Web UI では、Add Zone または Edit Zone ページで Secondary Expire フィールドに有効期限を設定します。デフォルトは 7 日です。必要な変更を行ったら、 Modify Zone をクリックします。

ローカル クラスタ CLI では、 zone name set expire を使用します。

グルー レコードの取り込み

グルー レコードとは、ゾーンまたはサブゾーンの権限ネームサーバのアドレスを指定する DNS A レコードです。これはクエリー応答の情報レコードです。たとえば、ほとんどの回答には NS レコードが含まれています。その後、NS レコード名をアドレスに解決するために、A レコードの取り込みが行われます。この A レコードがグルー レコードです。 no-fetch-glue アトリビュートを選択することは、通常は検索しないレコードをサーバに検索するように指示することを意味します。その結果、サーバは以降のクエリーの回答の中に、これらのレコードを含めることができます。

ローカル クラスタ Web UI では、Edit DNS Server ページの Don't fetch missing glue records がディセーブルに設定されていることを確認します。

CLI では、 dns disable no-fetch-glue (デフォルト)を使用します。

不完全な委任のレポート

不完全な委任は、親からゾーンを委任されている DNS サーバが、そのゾーンに対して権限を持っていることを知らない場合に発生します。この不完全な委任をサーバが検知して報告できるのは、回答をトラッキングしている過程で、回答を参照したサーバが、次にルートにより近いドメイン(実際は回答からさらに遠い)の別のサーバを参照したときです。不完全な委任は、DNS コンフィギュレーションの問題を表すものではなく、照会先の DNS サーバのコンフィギュレーションに問題があることを表します。そのドメインでも権限がある場合以外は、他のドメイン上の不完全な委任は修正できません。

Report lame delegations lame-deleg-notify )アトリビュートの設定は、DNS ログ設定である lame-delegation と同じ効果を持つことに注意してください。

ローカル クラスタ Web UI では、Edit DNS Server ページの Report lame delegations がイネーブルに設定されていることを確認します。

ローカル クラスタ CLI では、 dns enable lame-deleg-notify (デフォルト)を使用します。

最大否定キャッシュ時間の設定

同じ情報に対して繰り返される要求に迅速に応答できるように、DNS サーバは、そのクライアントのために他のサーバから得たデータのキャッシュを保持します。これには、RFC 2308 で規定されている「no such name」(該当名がありません)や「no such data」(該当データがありません)といった否定情報も含まれます。この情報は、権限ソースでのネームスペース変更に対応するために、ある時点で廃棄することが重要です。

最大否定キャッシュ時間は、否定キャッシュ エントリが有効な時間の上限を確立します。この値は、否定応答の SOA レコードから取得します。発信側のゾーンで TTL の値が異常に大きい場合、最大否定キャッシュ時間の値はその値を縮小し、エントリが否定的にキャッシュされる時間を制限します。長い否定キャッシュ エントリを排除する必要性と意味のある否定応答をキャッシュする利点とのバランスを考えて慎重に値を選択します。

最大キャッシュ TTL 値は、否定と肯定の両方を含むすべてのキャッシュ エントリに適用されるため、最大否定キャッシュ時間を効果的に短縮できることに注意してください。「最大キャッシュ TTL の設定」の項を参照してください。 max-cache-ttl max-negcache-tll の TTL 値の小さい方が、否定エントリのキャッシュ時に優先されます。

ローカル クラスタ Web UI では、Edit DNS Server ページで、 Max. negative answer caching TTL 値を設定します。デフォルトは 1 時間です。

ローカル クラスタ CLI では、 dns set max-negcache-ttl を使用します。デフォルトは 60 分です。

最大キャッシュ TTL の設定

Maximum Cache TTL プロパティを使用すると、Network Registrar がキャッシュした情報を保持する最大時間を指定することができます。TTL は、任意のネーム サーバが他のネーム サーバから得たデータをキャッシュに保持することが許容される時間です。キャッシュに追加される各レコードには、TTL 値が付加されています。TTL 期間が経過すると、サーバは、キャッシュしたデータを放棄し、次のクエリーを送信したときに権限ネームサーバから新しいデータを取得する必要があります。このパラメータは、キャッシュ内の TTL 値が非常に大きいレコードのライフタイムを制限します。デフォルト値は 7 日間(604800 秒)です。

Web UI では、Edit DNS Server ページで Max. resource record caching TTL 値を設定します。デフォルトは 1 週間です。

ローカル クラスタ CLI では、 dns set max-cache-ttl を使用します。

最大メモリ キャッシュ サイズの設定

Maximum Memory Cache Size プロパティを使用すると、DNS メモリ内キャッシュ用に確保するメモリ領域の大きさを指定できます。キャッシュのメモリが大きいほど、サーバがディスク キャッシュを使用する回数が少なくなります。デフォルトは 200 KB です。1 エントリは、約 100 バイトです。

Web UI では、Edit DNS Server ページで Max. memory cache size 値を設定します。デフォルトは 200 KB です。

ローカル クラスタ CLI では、 dns set mem-cache-size を使用します。

DNS キャッシュのフラッシュ

Network Registrar のキャッシュ フラッシング機能を使用すると、ディスク キャッシュ ファイルの肥大化を防ぐことができます。しかし、実際の動作は、DNS サーバが動作中か停止中かによって異なります。キャッシュをフラッシュすると次のように処理されます。

サーバの動作中、Network Registrar は、キャッシュ データベース ファイルからすべての不要なエントリを消去します。データベースの性質上、キャッシュをフラッシュしても、ファイルのサイズは小さくなりませんが、ファイル内に空き領域が作成されます。メモリ キャッシュはこの操作の影響を受けないので、最近使用されたキャッシュ エントリが失われることはなく、またパフォーマンスに大きな影響が出ることもありません。

サーバが停止すると、Network Registrar は、すべてのエントリをフラッシュし、キャッシュ ファイルを削除する要求を解釈します。サーバを再起動すると、データベースが再初期化されます。

サイズが大きくなりすぎたキャッシュをクリアするには、または解決例外を変更する場合には、サーバを停止し、コマンドを入力してからサーバを再起動します。サーバを停止してもサーバ プロセスが終了するのではなく、それ以上の要求を処理しなくなるだけです。解決例外の詳細については、「解決例外の使用」を参照してください。

ローカル クラスタ Web UI では、Manage DNS Server ページで Commands カラムの Run アイコン( )をクリックし、DNS Server Commands ページを開きます(図6-3 を参照)。このページで、Flush cache の横の Run アイコン( )をクリックします。特定の時間よりも古いキャッシュをフラッシュする場合は、Flush cache older than の横の Time フィードに時間を入力し、Run アイコンをクリックします。

ローカル クラスタ CLI では、 dns flushCache を使用します。

不良 Address レコードと他のキャッシュ アトリビュート

不良ホスト ターゲット Address(A) RR がキャッシング DNS サーバに照会すると、不審な DoS 攻撃(サービス拒絶攻撃)の被害に遭うことがあります。このような A レコード クエリーには、IP アドレスに似た名前が入っています。DNS サーバの cache.db ファイルが、ルートからの否定応答で過負荷になることを防ぐには、サーバがこれらのクエリーの解決を試行しないようにします。 fake-ip-name-response DNS アトリビュート(Web UI では Fake Responses for IP address-like names )は、これに効果を及ぼすためにデフォルトでイネーブルになっています。サーバは権限のない名前に対するクエリーを受信すると、キャッシュ データを検索します。キャッシュ データでクエリーを解決できなければ、サーバはクエリーの値が IP アドレス(ドットで区切られた 4 つの 10 進数で、先頭にも末尾にも文字がない)に似ているかどうかを判別します。似ている場合、そのクエリーを転送しません。代わりに、サーバは、NAME ERROR(NXDOMAIN)戻りコードによって応答を返し、キャッシュには否定応答を保存しません。

サーバは、メモリ キャッシュから cache.db ファイルへエントリを転送するとき、
save-negative-cache-entries
アトリビュート(Web UI では Save negative cache entries to disk )および cache-write-ttl-threshold アトリビュートに基づいて動作します。これは、通常、メモリ内キャッシュが満杯になり、サーバが新しいエントリを挿入する必要があるときに起こるメモリ内キャッシュからの肯定クエリー応答と否定クエリー応答の転送です。サーバは、least-recently-used エントリも転送します。 save-negative-cache-entries をディセーブルにすると、サーバは転送した否定エントリを cache.db ファイルに格納せず、単にメモリ内サーバ キャッシュから破棄します。
cache-write-ttl-threshold
の値が 0 以外の場合(デフォルトは 0)、エントリの TTL がこの値より大きいとき、サーバはエントリをメモリ内キャッシュから cache.db ファイルに保持するだけです。それ以外のとき、サーバは(すぐに期限切れになるが、まだなっていない) RR を破棄します。値が 0 の場合は、サーバが常に期限満了していない RR を保持することになります。

ローカル クラスタ Web UI では、Edit DNS Server ページで Fake responses for IP address-like names をイネーブル(デフォルト)に設定し、 Save negative cache entries to disk をディセーブル(デフォルトはイネーブル)に設定します。

ローカル クラスタ CLI では、 fake-ip-name-response アトリビュートと save-negative-cache-entries アトリビュートをそれぞれイネーブルに設定します。

クエリー ソース アドレスおよびポート番号の設定

クエリー発信元アドレスは、クライアントの名前解決時に DNS サーバが他のサーバにクエリーを送信する発信元 IP アドレスです。値に 0.0.0.0 を設定すると、宛先に基づいて最適なローカル アドレスを使用するという意味になります。

クエリー発信元ポートは、クライアントの名前解決時に DNS サーバが他のサーバにクエリーを送信する発信元 UDP ポート番号です。値にゼロを設定すると、サーバがファイアウォールの背後にある場合のように、ランダム ポートの選択が必要であるという意味になります。値の設定を解除すると、ローカル ポートから値を送信します(「ローカル ポート番号と外部ポート番号の設定」を参照)。

ローカル クラスタ Web UI では、Edit DNS Server ページで Query source IP address アトリビュートと Query source UDP port アトリビュートを設定します。

ローカル クラスタ CLI では、 dns set query-source-address dns set query-source-port を使用します。

ローカル ポート番号と外部ポート番号の設定

新しいネームサーバのグループを実験する場合、要求に回答したりリモート データを要求するときに非標準ポートを使用する必要がある場合があります。ローカル ポート設定と外部ポート設定は、サーバが名前解決要求を受信する TCP ポートと UDP ポート、およびサーバが他のネームサーバに対して要求を出すときに接続するポートを制御します。標準値は、どちらの場合もポート 53 です。正常動作時にこの値を変更すると、サーバが利用不可能になったように見えます。

ローカル クラスタ Web UI では、Edit DNS Server ページで Listening port および Remote DNS servers port をデフォルトの 53 以外のポートに設定します。

ローカル クラスタ CLI では、 dns set local-port-num dns set remote-port-num を使用します。

DNS プロパティの調整

ここでは、DNS サーバ プロパティを調整する場合の推奨事項について説明します。

Notify send min. interval DNS サーバ アトリビュート(CLI では notify-min-interval コマンド):同一のゾーンに対して連続して変更を加えることを示す通知をサーバに送信する前に必要な最小間隔。デフォルトは 2 秒です。非常に大きなゾーンでは、発信完全ゾーン転送を送信する最大時間よりこの値を大きくすることができます。これは、着信差分ゾーン転送を受信し、他のセカンダリに完全転送を送信するセカンダリ サーバで推奨されます。たとえば、差分ゾーン転送をサポートしない旧式の BIND サーバなどがこれにあたります。着信差分転送は、発信完全転送を中断する場合があります。

Notify delay between servers DNS サーバ アトリビュート(CLI では notify-send-stagger コマンド):ある変更についての複数のサーバへの通知をずらす間隔。多数のゾーン転送を複数のサーバ間でサポートする場合は、5 秒程度に設定するのが適切です。

Notify wait for more changes DNS サーバ アトリビュート(CLI では notify-wait コマンド):最初のゾーン変更の後から、他のネームサーバへの変更通知を送信する前までの遅延時間。ただし、 notify-min-interval アトリビュートと同じ理由により、15 秒程度が適切です。

Max. memory cache size DNS サーバ アトリビュート(CLI では mem-cache-size コマンド):メモリ内レコード キャッシュのサイズ(キロバイト単位)。デフォルトは 200 KB です。大規模ネットワークでは 1000 KB 程度まで上げる場合もあります。

Report lame delegations DNS サーバ アトリビュート(CLI では lame-deleg-notify コマンド):親ゾーンのサブゾーンの委任にリストされた DNS サーバ がゾーンの権限サーバであることを認識していない場合は、Network Registrar が感知して記録する必要があります。これは通常ディセーブルですが、イネーブルにするとよい場合があります。このアトリビュートには、ログ設定を lame-delegation に設定したときと同じ効果があります。

Edit DNS Server ページの Foreign Servers セクションの IXFR チェックボックス、または CLI の場合は remote-dns address/mask create ixfr :1 台のサーバまたはサーバのグループにエントリを追加すると、それらのサーバからのゾーン転送を処理するときに IXFR を発生させるかどうかを制御できます。

DNS サーバのトラブルシューティング

DNS サーバを診断するために、次のような有用なトラブルシューティングのヒント ツールがあります。

ループバック ゾーンの復元:ループバック ゾーンとは、ホストがループバック アドレス(127.0.0.1)を localhost に解決するために使用する逆ゾーンです。ループバック アドレスにより、ネットワーク トラフィックをホスト自体に転送できるようになります。ループバック ゾーンは、手動で設定することも、既存の BIND ゾーン ファイルからインポートすることもできます(『 Network Registrar CLI Reference 』に記載されている zone コマンドの使用ガイドラインを参照してください)。

DNS サーバ プロパティの値のリスト表示:Web UI では、 DNS をクリックしてから DNS Server をクリックし、Edit DNS Server ページを開きます。CLI では、 dns show を使用します。

DNS ログ設定から選択して既存のログ メッセージを詳細に制御:Web UI の Edit DNS Server ページで Log settings アトリビュートを使用します。または、CLI で dns set log-settings と次のキーワードまたは数値をカンマで区切って使用します( 表16-1 を参照)。ログ設定を変更した場合は、サーバを再起動します。

 

表16-1 DNS ログ設定

ログ設定(対応する数値)
説明

config (1)

サーバの設定および初期化解除。

ddns (2)

高レベルなダイナミック アップデート メッセージ。

xfr-in (3)

着信完全および差分ゾーン転送。

xfr-out (4)

発信完全および差分ゾーン転送。

notify (5)

NOTIFY トランザクション。

datastore (8)

データストア処理。サーバの埋め込みデータベースにおけるさまざまなイベントの観察を助けます。

scavenge (9)

ダイナミック RR の清掃(「ダイナミック レコードの清掃」を参照)。

scavenge-details (10)

詳細な清掃出力(デフォルトではディセーブル)。

server-operations (11)

全般的な高レベル サーバ イベント。たとえば、ソケットやインターフェイスに関するイベントです。

lame-delegation (13)

不完全な委任イベント。デフォルトではイネーブルですが、このフラグをディセーブルにすることによって、不完全な委任イベントが頻繁に起きても、そのためにログが満杯になるのを防止できます。

root-query (14)

ルート サーバからのクエリーと応答。

ddns-refreshes (15)

Windows 2000 クライアント用 DNS アップデート リフレッシュ(デフォルトはディセーブル)。

ddns-refreshes-details (16)

Windows 2000 クライアント用 DNS アップデート時にリフレッシュされた RR (デフォルトはディセーブル)。

ddns-details (17)

DNS アップデートのために追加または削除された RR。

tsig (18)

Transaction Signature(TSIG) DNS アップデートに関連するログ イベント(「トランザクション セキュリティ」を参照)。

tsig-details (19)

TSIG DNS アップデートの詳細なロギング(デフォルトはディセーブル)。

activity-summary (20)

サーバのアクティビティの要約。これらの要約を収集する間隔は、 activity-summary-interval アトリビュートを使って調整できます。デフォルトは 5 分間隔です(この間隔は、 dns set-activity-summary-interval を使用して調整できます)。

query-errors (21)

DNS クエリー処理中に発生したログ エラー。

config-details (22)

サーバ設定時の詳細情報を生成。すべての設定済みおよび前提となるサーバ アトリビュートを表示します(デフォルトはディセーブル)。

incoming-packets (23)

着信データ パケット。

outgoing-packets (24)

発信データ パケット。

xfer-in-packets (25)

完全ゾーン転送(XFR)着信パケット。

query-packets (26)

着信クエリー パケット。

notify-packets (27)

NOTIFY パケット。

ddns-packets (28)

DNS アップデート パケット。

xfer-out-packets (29)

発信 XFR パケット。

ha-details (30)

ハイ アベイラビリティ(HA)DNS 情報の詳細なロギングを生成します。

nslookup ユーティリティを使用して、DNS 設定をテスト、確認します。このユーティリティは、インターネット ネームサーバにクエリーを送信する単純なリゾルバです。 nslookup ユーティリティのヘルプを表示するには、コマンドを起動した後、プロンプトで help と入力します。末尾のドットが付いた完全修飾名だけを使用し、ルックアップが適切に処理されるようにします。 nslookup を実行すると、最初にネームサーバ自体の逆クエリーが実行されます。サーバの設定が原因でサーバが解決できない場合、このクエリーは失敗することがあります。 server コマンドを使用するか、コマンド ラインでサーバを指定して、適切なサーバに対してクエリーを実行していることを確認します。 -debug または -d2 フラグを使用して、送信された応答と( -d2 を使用した場合は)クエリーをダンプします。