ドメインネームシステムがGSLBをサポートする方法

最終公開日 : Sep 25, 2026
ドメインネームシステム (DNS) は、クライアント/サーバーアーキテクチャを使用する分散データベースと見なされます。ネームサーバーはアーキテクチャ内のサーバーであり、リゾルバは、ネットワークを介してクエリを作成して送信するオペレーティングシステムにインストールされているライブラリルーチンであるクライアントです。
DNS の論理階層を次の図に示します。
論理 DNS 階層
注：
第 2 レベルのルートサーバーは、.com、.net、.org、.gov ドメインなどのネームサーバー委任のネームサーバーからアドレスへのマッピングを維持する責任があります。第 2 レベルドメイン内の各ドメインは、下位レベルの組織ドメインのネームサーバからアドレスへのマッピングを維持する責任があります。組織レベルでは、WWW、FTP、およびその他のサービスを提供するホストに対して、個々のホストアドレスが解決されます。
Related information

委任

現在の DNS トポロジの主な目的は、1 つの機関ですべてのアドレスレコードを維持する負担を軽減することです。これにより、組織の名前空間を特定の組織に委任できます。その後、組織はそのスペースを組織内のサブドメインにさらに委任できます。たとえば、citrix.com では、 sales.citrix.com、 education.citrix.com、support.citrix.comというサブドメインを作成できます。対応する部門は、サブドメインに対して権限のある独自のネームサーバーセットを保持し、ホスト名とアドレスマッピングの独自のセットを維持できます。すべてのCitrix アドレスレコードを管理する責任は、単一の部門ではありません。各部門は、アドレスを変更したり、トポロジを変更したり、上位レベルのドメインや組織でより多くの作業を課すことはありません。

階層トポロジの利点

階層トポロジの利点には、次のようなものがあります。
  • スケーラビリティ
  • キャッシュ機能を各レベルでネームサーバーに追加する。DNS 要求は、特定のドメインに対して権限がないがクエリへの応答を提供できるホストによって処理され、輻輳と応答時間が短縮されます。
  • キャッシングは、サーバー障害に対する冗長性と回復力ももたらします。1 つのネームサーバーに障害が発生しても、同じレコードの最近キャッシュされたコピーを持つ他のサーバーからレコードを提供できる可能性があります。

リゾルバ

リゾルバは DNS システム内のクライアントコンポーネントです。ドメイン・ネーム・スペースからの情報を必要とするホスト上で実行されているプログラムは、リゾルバを使用します。リゾルバは次の処理を行います。
  • ネームサーバを照会する。
  • レスポンスの解釈（リソースレコードまたはエラーなど）。
  • 情報を要求したプログラムに情報を返します。
リゾルバは、telnet、FTP、ping などのプログラムにコンパイルされるライブラリルーチンのセットです。それらは別々のプロセスではありません。リゾルバはクエリをまとめ、送信し、回答を待つことができます。また、特定の時間内に返答されない場合は、もう一度送信してください (おそらくセカンダリネームサーバに)。これらのタイプのリゾルバは、スタブ・リゾルバと呼ばれます。一部のリゾルバーには、レコードをキャッシュし、存続時間 (TTL) を尊重する機能が追加されています。Windows では、この機能は DNS クライアントサービスを通じて使用できます。「services.msc」コンソールから表示できます。

ネームサーバー

ネームサーバーは通常、ドメインネームスペース (ゾーンと呼ばれる) の特定の部分に関する完全な情報を格納します。ネームサーバーには、そのゾーンに対する権限があると言われます。また、複数のゾーンに対して権限を持つこともできます。
ドメインとゾーンの違いは微妙です。ドメインとは、サブドメインを含むエンティティの完全なセットであり、ゾーンはドメイン内の情報であり、別のネームサーバーに委任されません。ゾーンの例としては citrix.com、サブドメイン内の別のネームサーバーにゾーンが委任されている場合、sales.citrix.comは別のゾーンです。この場合、プライマリCitrix ゾーンには citrix.com、 it.citrix.com、およびsupport.citrix.comを含めることができます 。sales.citrix.comが委任されるため、 citrix.comネームサーバが権限を持つゾーンの一部ではありません。次の図は、2 つのゾーンを示しています。
DNS ゾーン
サブドメインを適切に委任するには、サブドメインの権限を別のネームサーバーに割り当てる必要があります。前の例では、 ns1.citrix.comにはsales.citrix.com サブドメインに関する情報は含まれていません。代わりに、 ns1.sales.citrix.com サブドメインに対して権限のあるネームサーバーへのポインタが含まれます。

ルートネームサーバーとクエリ解決

ルートネームサーバは、第 2 レベルドメインに対して権限を持つすべてのネームサーバの IP アドレスを認識します。ネームサーバーが独自のデータファイルに特定のドメインに関する情報を持っていない場合、最終的に特定のドメインに到達するために、 DNS ツリー構造の適切なブランチを走査するためにルートサーバーに連絡するだけで済みます。これには、ツリートラバーサルで次の権限のあるネームサーバーを見つけるための複数のネームサーバーへの一連の要求が含まれます。このリクエストは、さらなる解決のために連絡する必要があります。
次の図は、トラバーサル中に要求された名前のキャッシュレコードがないと仮定した、典型的な DNS 要求を示しています。次の例では、Citrix ドメインのモックアップを使用します。
DNS ゾーン

再帰クエリと非再帰クエリ

上記の例では、発生する 2 つのタイプのクエリを示します。
  • 再帰クエリ:リゾルバとローカルに設定されたネームサーバー間のクエリは再帰的です。つまり、ネームサーバーはクエリを受信し、クエリが完全に応答されるか、エラーが返されるまでリゾルバに応答しません。ネームサーバがクエリへの参照を受信すると、ネームサーバが最終的に返された回答（IP アドレス）を受け取るまで、ネームサーバは参照に従います。
  • 非再帰クエリ:ローカルで構成されたネームサーバーが、後続の権限のあるドメインレベルのネームサーバーに対して行うクエリは、非再帰 (または反復) です。各リクエストは、下位レベルの権限のあるサーバーへの参照、またはクエリに対する応答のいずれかで即座に応答されます（クエリされたネームサーバーがそのデータファイルまたはそのキャッシュに回答が含まれている場合）。

キャッシュ

解決プロセスには関与しており、複数のホストへの小さなリクエストが必要になる可能性がありますが、高速です。DNS 解決の速度を上げる要因の 1 つがキャッシュです。ネームサーバーは、再帰クエリを受信するたびに、最終的に特定の要求に対して適切な権限のあるサーバーに到達するために、他のサーバーと通信しなければならない場合があります。これは、将来の参照のために受け取ったすべての情報を格納します。次のクライアントが、別のホストで同じドメイン内で同様の要求を行う場合、そのドメインに対して権限のあるネームサーバーをすでに認識しており、ルートネームサーバーで起動するのではなく、そこで直接リクエストを送信できます。
キャッシュは、存在しないホストのクエリなど、否定的な応答に対しても発生する可能性があります。この場合、サーバは、ホストが存在しないことを把握するために、要求されたドメインを権限のあるネームサーバに照会してはなりません。時間を節約するために、ネームサーバーはキャッシュをチェックし、ネガティブレコードで応答します。
ネームサーバーはレコードを無期限にキャッシュしないか、IP アドレスを更新することはできません。同期の問題を回避するために、DNS 応答には存続時間 (TTL) が含まれています。このフィールドは、キャッシュがレコードを破棄し、更新されたレコードがあるかどうかを権限のあるネームサーバーで確認する前に、キャッシュがレコードを保存できる時間間隔を示します。レコードが変更されていない場合、TTL を使用すると、GSLB を実行するデバイスからの迅速な動的応答も可能になります。

リソースレコードタイプ

さまざまな RFC は、DNS リソースレコードタイプとその説明の包括的なリストを提供します。次の表に、一般的なリソースレコードタイプを示します。
リソースレコードタイプ 説明 RFC
A ホストアドレス RFC 1035
NS 権威あるネームサーバー RFC 1035
MD メールの送信先 (廃止-MX を使用) RFC 1035
MF メールフォワーダー (廃止-MX を使用) RFC 1035
CNAME エイリアスの正規名 RFC 1035
SOA 権限ゾーンの開始をマークします。 RFC 1035
WKS よく知られているサービスの説明 RFC 1035
PTR ドメイン名ポインタ RFC 1035
ヒント ホスト情報 RFC 1035
MINFO メールボックスまたはメールリストの情報 RFC 1035
MX メール交換 RFC 1035
TXT テキスト文字列 RFC 1035
AAAA IP6 アドレス RFC 3596
SRV サーバー選択 RFC 2782]

GSLB がDNSをサポートする方法

GSLB は、DNS クエリで送信する必要がある IP アドレスを決定するアルゴリズムとプロトコルを使用します。GSLBサイトは地理的に分散されており、NetScaler ADCアプライアンスでサービスとして実行されている各サイトにはDNS権限のあるネームサーバーがあります。関係するさまざまなサイトのすべてのネームサーバーは、同じドメインに対して権限を持ちます。各 GSLB ドメインは、委任が設定されるサブドメインです。したがって、GSLB ネームサーバーは権限があり、さまざまな負荷分散アルゴリズムのいずれかを使用して、どの IP アドレスを返すかを決定できます。
委任は、親ドメインのデータベースファイルに GSLB ドメインのネームサーバーレコードを追加し、委任に使用されるネームサーバーのアドレスレコードを追加することによって作成されます。たとえば、www.citrix.comにGSLBを使用する場合は、次のバインドSOAファイルを使用して、リクエストをwww.citrix.comからネームサーバーに委任できます。Netscaler1とNetscaler2。
###########################################################################
@ IN SOA citrix.com. hostmaster.citrix.com. (
1 ; serial
3h ; refresh
1h ; retry
1w ; expire
1h ) ; negative caching TTL
IN NS ns1
IN NS ns2
IN MX 10 mail

ns1   IN A 10.10.10.10
ns2   IN A 10.10.10.20
mail  IN A 10.20.20.50

### Old Configuration if www was not delegated to a GSLB name server
www IN A 10.20.20.50

### Updated Configuration
Netscaler1 IN A xxx.xxx.xxx.xxx
Netscaler2 IN A yyy.yyy.yyy.yyy
www IN NS Netscaler1.citrix.com.
www IN NS Netscaler2.citrix.com.
###
IN MX 20 mail2
mail2 IN A 10.50.50.20
###########################################################################
BIND を理解することは、DNS を設定するための要件ではありません。準拠する DNS サーバーの実装には、同等の委任を作成する方法があります。Microsoft DNS サーバーを委任用に構成するには、「 (https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc785881(v=ws.10)」の手順を使用します。redirectedfrom =MSDN)。
NetScaler ADCアプライアンスのGSLBが標準のDNSサービスを使用してトラフィックを分散するのとは異なるのは、NetScaler GSLBサイトがメトリック交換プロトコル（MEP）と呼ばれる独自のプロトコルを使用してデータを交換することです。MEP を使用すると、GSLB サイトは他のすべてのサイトに関する情報を維持できます。DNS 要求を受信すると、MEP は GSLB メトリックスを考慮して、次のような情報を決定します。
  • 現在の接続数が最も少ないサイト
  • ラウンドトリップ時間 (RTT) に基づいてリクエストを送信した LDNS サーバーに最も近いサイト。
使用できる負荷分散アルゴリズムはいくつかありますが、GSLBは、参加サイトのメトリックに基づいてどのアドレスを送信する必要があるかをネームサーバー（NetScaler ADCアプライアンス上でホストされている）に知らせるDNSです。
GSLB が提供するその他の利点は、永続性（またはサイトアフィニティ）を維持できることです。着信 DNS クエリに対する応答をソース IP アドレスと比較して、そのアドレスが最近特定のサイトに誘導されたかどうかを判断できます。その場合は、クライアントセッションが確実に維持されるように、同じアドレスが DNS 応答に送信されます。
別の形式の永続性は、HTTP リダイレクト、または HTTP プロキシを使用してサイトレベルで取得されます。これらの形式の永続性は、DNS 応答が発生した後に発生します。したがって、リクエストを別の参加サイトに誘導する Cookie を含むサイトで HTTP リクエストを受け取った場合、リダイレクトで応答するか、リクエストを適切なサイトにプロキシすることができます。

メトリック交換プロトコル

メトリック交換プロトコル (MEP) は、GSLB 計算で使用されるデータをサイト間で共有するために使用されます。MEP 接続を使用して、3 種類のデータを交換します。これらの接続は、TCP ポート 3011 を介してセキュアである必要はなく、TCP ポート 3009 経由の SSL を使用してセキュアにすることもできます。
以下の3種類のデータが交換され、独自の間隔と交換方法がある。
  • サイトメトリック交換: これはポーリング交換モデルです。たとえば、site1 に site2 サービスの構成がある場合、第 2 サイト1 は site2 に GSLB サービスのステータスを要求します。Site2 は、状態およびその他のロードの詳細で応答します。
  • ネットワークメトリック交換： これは、動的近接負荷分散アルゴリズムで使用される LDNS RTT 情報交換です。これはプッシュ交換モデルです。5 秒ごとに、各サイトはそのデータを他の参加サイトにプッシュします。
  • 永続性交換: これは SOURCEIP 永続性交換用です。これはプッシュ交換モデルでもあります。5 秒ごとに、各サイトはそのデータを他の参加サイトにプッシュします。
デフォルトでは、サイトサービスはポーリング情報のみに基づいて MEP を介して監視されます。モニタ間隔に基づいてモニタをバインドすると、状態は更新され、それに応じてモニタリング間隔を設定することで更新の頻度を制御できます。