「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
DNSサーバによる名前解決の仕組み †
- DNSサーバは、FQDN名をIPアドレスに変換するサーバである。
特にインターネット上のDNSサーバは、ドメイン階層に合わせて配置されたDNSサーバが
連携して動作する名前解決用の広域ディレクトリ サービスである。
- DNSサーバの名前解決の仕組みについて以下説明する。
- DNSサーバは、UDPポート53番でDNSクエリ(ユニキャスト)を受信し、
(ただし、DNSメッセージが512オクテットを超えた場合はTCPポート53番を使用する)。
- DNSクライアントに結果となるIPアドレスを返す名前解決システムである。
DNSクライアントは、UDPポート53番で応答(ユニキャスト)を受信する。
- また、ゾーン転送 の際は、信頼性を確保するためTCPポート53番を使用する。
- DNSクライアントは、DNSサーバのIPアドレスを知るためにDNSサーバを使うことはできないので、
あらかじめDNS クライアントにDNSサーバのIPアドレスを設定するかDHCPを使用して配信する必要がある。
DNSサーバの種類 †
DNSサーバには、
- サーバ
- コンテンツ サーバ
- フルサービス リゾルバ(キャッシュ サーバ)
- スレーブ サーバ
- フォワーダ
などの種類がある。
次に、これらのDNSサーバの種類と特長について説明する。
コンテンツ サーバ †
- 「コンテンツ サーバ」は、自分が管理しているゾーンに対するDNSクエリだけに回答し、
名前解決ができなくても他のDNSサーバにDNSクエリを送信しないDNSサーバである。
- インターネット上に「コンテンツ サーバ」を配置する場合は、
- 上位のドメインの「コンテンツ サーバ」から「委任」されている必要がある。
- ここではDNSのドメインを指す。機能的に見て、ADのドメインとは完全に一致しないので注意する。
- DNSでは、ドメインを複数のサブドメインに分割し、「委任」により親ドメインから子ドメインを信頼して管理を分散する。
- 「コンテンツ サーバ」はドメイン階層に合ったドメイン ツリー構造をとる 。
- インターネット上のドメイン ツリーは、「委任」により世界中のDNSサーバをつなぐ「信頼の連鎖」ツリーでもある。
- コンテンツ サーバのドメイン ツリー構造
フルサービス リゾルバ(キャッシュ サーバ) †
- 「コンテンツ サーバ」はドメイン ツリー構造をとることがあるので、実際に名前解決する場合は、ドメイン ツリー上の「コンテンツ サーバ」をルートから走査して名前解決のためのレコードを検索する必要がある。
- このようにドメイン ツリー上の「コンテンツ サーバ」をルートから走査して名前解決のためのレコードを検索するDNSクエリを「反復クエリ」と呼ぶ。
- これに対して、自身がドメイン ツリー上の「コンテンツ サーバ」を走査することなく、他のDNSサーバにこのような処理を依頼するためのDNSクエリを「再帰クエリ」と呼ぶ。
- クライアントPCなどが送信する「再帰クエリ」を受信し、ドメイン ツリー上の個々の「コンテンツ サーバ」に「反復クエリ」を送信するDNSサーバを「フルサービス リゾルバ」と呼ぶ。
- 「フルサービス リゾルバ」は、「再帰クエリ」で要求された名前解決が完了するまで、他のDNSサーバに「反復クエリ」を送信する 。
- 「フルサービス リゾルバ」には、「ルート ヒント」として「ルート ネーム サーバ」のIPアドレスを設定する。
- また、各「コンテンツ サーバ」は、NSレコードに下位ドメイン(委任先)の「コンテンツ サーバ」の名前とIPアドレスを持っている。
- このため「フルサービス リゾルバ」は、「ルート ネーム サーバ」からの走査(反復クエリの実行)が可能になる。
- また、同じ問い合わせを何度も繰り返すという非効率を避けるため、一度名前解決をした情報を内部にキャッシュして再利用することから「キャッシュ サーバ」とも呼ばれる。
- また、「コンテンツ サーバ」と「フルサービス リゾルバ」の両方の機能を持つようなDNSサーバも存在する。
スタブ リゾルバとスレーブ サーバ †
スタブ リゾルバ †
「フルサービス リゾルバ」に「再帰クエリ」を送信する、端末側で動作する「リゾルバ」(DNSクライアント)を「スタブ リゾルバ」と呼ぶ。
スレーブ サーバ †
また、「再帰クエリ」を他サーバへ転送し、自身は「反復クエリ」を送信しない「スタブ リゾルバ」機能だけを実装しているDNSサーバを俗に「スレーブ サーバ」と呼ぶ。
条件付きフォワーダとスタブ ゾーン †
コンテンツ サーバがDNS クエリを処理する際、
「別のDNS サーバを紹介したり別のDNS サーバへDNS クエリを転送したりする機能」
に「条件付きフォワーダ」と「スタブ ゾーン」がある。
条件付きフォワーダ †
- 内部ドメイン(イントラネット)で名前解決できないDNSクエリなどを、
外部ドメイン(インターネット)に転送する場合、「条件付きフォワーダ」を定義してDNSクエリを転送する。
- 「条件付きフォワーダ」では、特定のドメイン名に基づいてDNSクエリを転送することもできる。また、転送先のDNSサーバを「フォワーダ」と呼ぶ。
- 企業の合併により、2つの異なる内部ドメイン(イントラネット)で、
名前解決が必要になる場合などにも、この「条件付きフォワーダ」が利用できる。
スタブ ゾーン †
- 「委任」では、親ドメインの管理者は子ドメインのゾーン データをホストするコンテンツ サーバのFQDN名とIPアドレスの
レコードを手動で管理する必要があるが、「スタブ ゾーン」を利用することで、この管理を自動化できる。
- 「スタブ ゾーン」には、子ドメインのマスタ サーバ のIPアドレスを持つレコードが含まれており、
子ドメインのマスタ サーバと通信することで最新のゾーン データを取得できる。
- マスタ サーバは、
- 子ドメインの「[[プライマリ ネームサーバ>]]」
- または「[[セカンダリ ネームサーバ>]]」
である。
これにより、「スタブ ゾーン」をホストする親ドメインの「コンテンツ サーバ」では、子ドメインの管理を自動化できる。
また、「スタブ ゾーン」をホストする親ドメインのコンテンツ サーバが、子ドメインに対するDNSクエリを受信した場合、次のような処理を実行する。
- 再帰クエリの場合
親ドメインのコンテンツ サーバは「スタブ ゾーン」のレコードを使って、子ドメインのコンテンツ サーバに「反復クエリ」を送信する。
- 反復クエリの場合
親ドメインのコンテンツ サーバは「スタブ ゾーン」のレコードを使って、子ドメインのコンテンツ サーバへの紹介を返す。
BBルータを使用した家庭LANの例 †
例えば、家庭LANのBBルータなどは「スレーブ サーバ」的な機能を提供する。
BBルータを使用した家庭LAN上のPCで「ipconfig /all」コマンドを実行すると、
BBルータ上のDHCPサーバから、デフォルト ゲートウェイ・DNSサーバ(スレーブ サーバ)
にBBルータのIPアドレスが設定されていることを確認できる。
>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : (ホスト名)
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter ローカル エリア接続:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : (NIC名)
Physical Address. . . . . . . . . : (NICのMACアドレス)
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : (ローカルマシンのIPアドレス)
Subnet Mask . . . . . . . . . . . : (サブネット マスク)
Default Gateway . . . . . . . . . : (BBルータのIPアドレス)
DNS Servers . . . . . . . . . . . : (BBルータのIPアドレス)
この場合、プロバイダ指定のDNSサーバがフルサービス リゾルバに相当する。
ゾーン †
各ノードで管理されるDNS情報の単位を「ゾーン」と呼ぶ。
- 「ゾーン」は、1個から複数個のドメインの情報を記載する。
- 「ゾーン」が複数のDNSサーバに跨って保持されることは無い。
前方参照ゾーン・逆引き参照ゾーン †
前方参照ゾーン †
- 「前方参照ゾーン」とは、DNSによる正引き名前解決に必要なゾーン データであり、必ず作成する必要がある。
- 一般的にコンテンツ サーバのドメイン ツリー構造といった場合、「逆引き参照ゾーン」のツリー構造を指す。
逆引き参照ゾーン †
DNSによる逆引き名前解決に必要なゾーン データである。
- 「前方参照ゾーン」のコンテンツ サーバのドメイン ツリーとは別に、
「逆引き参照ゾーン」のコンテンツ サーバのツリーも存在する。
- ルート ネーム サーバは共通のコンテンツ サーバになっている。
- 「逆引き参照ゾーン」のトップ レベル ドメインとセカンド レベル ドメインは、「.in-addr.arpa」という特別な名前が付けられている。
- セカンド レベル ドメイン以降のドメイン名は、検索の基になるIPアドレスの各オクテットを逆順に並べたものになる。
- 例えば、「zzz.yyy.xxx.vvv」というIPアドレス(仮にクラスCのIPアドレスとする)のホストは、「arpa.in-addr.xxx.yyy.zzz」というゾーンに格納される。
クラスレス アドレッシング(CIDR)が適用された環境化では、この限りではない。
スタブ ゾーン †
「スタブ ゾーン」については、「スタブ ゾーン」で説明。
ゾーン レコード †
ゾーン データの単位を「レコード」、「リソース レコード」と言う。
DNSサーバの冗長化構成 †
プライマリ ネームサーバ・セカンダリ ネームサーバ †
- コンテンツ サーバには、冗長構成を組む時のために、
- 「プライマリ ネームサーバ」
- 「セカンダリ ネームサーバ」
の区分けがある。
- コンテンツ サーバは、冗長化による可用性の向上を要求されることがある。
- 例えば、インターネット上のjpドメインを管理するコンテンツ サーバは、
社団法人日本ネットワークインフォメーションセンター(JPNIC)の方針で、
2台のコンテンツ サーバを使い冗長化することが要求される。
- この冗長化の方式に
- 「プライマリ ネームサーバ」のゾーン データ(プライマリ ゾーン)を、
- 「セカンダリ ネームサーバ」のゾーン データ(セカンダリ ゾーン)に
- レプリケーションする「ゾーン転送」と呼ぶ方式がある。
プライマリ ネームサーバ †
「プライマリ ネームサーバ」は、「ゾーン ファイル」を自身で保存する。
セカンダリ ネームサーバ †
- 「セカンダリ ネームサーバ」は、ネットワークを経由して「プライマリ ネームサーバ」の「ゾーン ファイル」をレプリケーションする。
- 「セカンダリ ネームサーバ」は多くの場合、1台以上登録できる。
- 「フルサービス リゾルバ」は
- 「プライマリ ネームサーバ」・「セカンダリ ネームサーバ」を区別しない。
- 設定されている優先順位に合わせて、ネームサーバを選択し、
- 1つ目のネームサーバでうまく解決できなかった場合、
- 2つ目のネームサーバを使用する。
- また、類似した言葉に「優先DNSサーバ」・「代替DNSサーバ」があるが、
- これ自体が「フルサービス リゾルバ」(キャッシュ サーバ)であることもある。
- しかし、「優先DNSサーバ」・「代替DNSサーバ」と「プライマリ ネームサーバ」・「セカンダリ ネームサーバ」が対応しない場合もある。
ゾーン データをレプリケーションする、ゾーン転送の仕組み †
ゾーン データをレプリケーションする、「ゾーン転送」の仕組みの仕組みは、以下の通りである。
- セカンダリ ネームサーバは、セカンダリ ネームサーバの「SOA」レコードに含まれる「更新間隔」が経過したら、「SOA要求」を送信する。
- プライマリ ネームサーバは「SOA要求」を受信し、プライマリ ネームサーバの「SOA」レコードに含まれる「シリアル番号」を、「SOA返信」として返信する。
- セカンダリ ネームサーバは「シリアル番号」を参照し、ゾーン ファイルが更新されていることを確認する
(受信した「シリアル番号」が、自身の保持する「シリアル番号」より大きい場合、ゾーン ファイルが更新されていることを意味する)。
- ゾーン ファイルが更新されている場合、セカンダリ ネームサーバはゾーン ファイルの更新を確認し、「ゾーン転送要求」を送信する。
- プライマリ ネームサーバは「SOA要求」を受信し、ゾーン転送を開始する。この時、ゾーン転送の種類として「完全ゾーン転送 」・「差分 / 増分ゾーン転送 」を選択できる。
- 「完全ゾーン転送」(AXFR)
- すべての DNS サーバにサポートされている標準的なレプリケート処理で、ゾーン ファイル全体が「プライマリ ネームサーバ」から「セカンダリ ネームサーバ」にレプリケートされる。
- 「差分 / 増分ゾーン転送」(IXFR)
- 「差分 / 増分ゾーン転送」では、転送量を減らすことができる。
- 「プライマリ ネームサーバ」のゾーンの変更履歴から、「セカンダリ ネームサーバ」のゾーン ファイルとの差分 / 増分情報のみがレプリケートされる。
- 「プライマリ ネームサーバ」が「差分 / 増分ゾーン転送」をサポートしないか、またはゾーンの変更履歴がない場合は、「完全ゾーン転送」でレプリケートされる。
- セカンダリ ネームサーバは、この転送データをもとに、自身のゾーン ファイルを
最新の情報に更新し、新しいゾーン ファイルを有効にする。
※ゾーン転送は、
- 一般的にはセカンダリ ネームサーバ側から要求がされる(プル型)。
- ただし、プライマリ ネームサーバからゾーン ファイルの更新をセカンダリ ネームサーバに「通知」することもできる(プッシュ型)。
- また、信頼性を確保するためプロトコルにはTCPを使用する。
WindowsでのDNSクライアントの設定 †
以下に、WindowsでのDNSクライアントを構成する場合の設定方法を示す。
「優先DNSサーバ」・「代替DNSサーバ」の設定方法 †
DNSの検索サフィックスの設定方法 †
ローカルFQDN名生成の元情報の設定方法 †
ゾーン ファイルの動的更新の設定方法 †
イントラネット内の動的更新 †
インターネット環境の動的更新 †
DNSサーバの診断ツール †
nslookupコマンド? †
DNSListコマンド? †
参考 †
- @IT総合トップ > Master of IP Network
Tags: :Active Directory, :認証基盤, :ディレクトリ サービス