![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -戻る --[[ディレクトリ サービス]] --[[ドメイン サービス (AD DS)]] * 目次 [#c6e66bdb] #contents *概要 [#kee97f71] *DNSサーバによる名前解決の仕組み [#xd74ee28] -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サーバの種類 [#v94c4376] DNSサーバには、 -サーバ --コンテンツ サーバ --フルサービス リゾルバ（キャッシュ サーバ） --スレーブ サーバ --フォワーダ -クライアント --スタブ リゾルバ などの種類がある。 次に、これらのDNSサーバの種類と特長について説明する。 **コンテンツ サーバ [#ra8e5e47] -「コンテンツ サーバ」は、自分が管理している[[ゾーン>#e4aa5e9b]]に対するDNSクエリだけに回答し、~ 名前解決ができなくても他のDNSサーバにDNSクエリを送信しないDNSサーバである。 -インターネット上に「コンテンツ サーバ」を配置する場合は、~ --上位のドメインの「コンテンツ サーバ」から「委任」されている必要がある。~ ---ここではDNSのドメインを指す。機能的に見て、ADのドメインとは完全に一致しないので注意する。 ---DNSでは、ドメインを複数のサブドメインに分割し、「委任」により親ドメインから子ドメインを信頼して管理を分散する。 --「コンテンツ サーバ」はドメイン階層に合ったドメイン ツリー構造をとる 。 ---インターネット上のドメイン ツリーは、「委任」により世界中のDNSサーバをつなぐ「信頼の連鎖」ツリーでもある。 ---コンテンツ サーバのドメイン ツリー構造 #ref(DomainTree.png,left,nowrap,コンテンツ サーバのドメイン ツリー構造) **フルサービス リゾルバ（キャッシュ サーバ） [#a04f4c5b] -「コンテンツ サーバ」はドメイン ツリー構造をとることがあるので、実際に名前解決する場合は、ドメイン ツリー上の「コンテンツ サーバ」をルートから走査して名前解決のための[[リソースレコード>#yade5685]]を検索する必要がある。 -このようにドメイン ツリー上の「コンテンツ サーバ」をルートから走査して名前解決のための[[リソースレコード>#yade5685]]を検索するDNSクエリを「反復クエリ」と呼ぶ。 -これに対して、自身がドメイン ツリー上の「コンテンツ サーバ」を走査することなく、他のDNSサーバにこのような処理を依頼するためのDNSクエリを「再帰クエリ」と呼ぶ。 -クライアントPCなどが送信する「再帰クエリ」を受信し、ドメイン ツリー上の個々の「コンテンツ サーバ」に「反復クエリ」を送信するDNSサーバを「フルサービス リゾルバ」と呼ぶ。 -「フルサービス リゾルバ」は、「再帰クエリ」で要求された名前解決が完了するまで、他のDNSサーバに「反復クエリ」を送信する 。 --「フルサービス リゾルバ」には、「ルート ヒント」として「ルート ネーム サーバ」のIPアドレスを設定する。 --また、各「コンテンツ サーバ」は、[[NSリソースレコード>#i720ab0f]]に下位ドメイン（委任先）の「コンテンツ サーバ」の名前とIPアドレスを持っている。 --このため「フルサービス リゾルバ」は、「ルート ネーム サーバ」からの走査（反復クエリの実行）が可能になる。 --また、同じ問い合わせを何度も繰り返すという非効率を避けるため、一度名前解決をした情報を内部にキャッシュして再利用することから「キャッシュ サーバ」とも呼ばれる。 #ref(FullServiceResolver.png,left,nowrap,コンテンツ サーバ、フルサービス リゾルバ（キャッシュ サーバ）) -また、「コンテンツ サーバ」と「フルサービス リゾルバ」の両方の機能を持つようなDNSサーバも存在する。 --「[[条件付フォワーダ>#uda932eb]]」を実装する「コンテンツ サーバ」 --「[[スタブ ゾーン>#ta72a3a7]]」をホストする「コンテンツ サーバ」 **スタブ リゾルバとスレーブ サーバ [#y5fadfd0] ***スタブ リゾルバ [#vf9123a0] 「フルサービス リゾルバ」に「再帰クエリ」を送信する、端末側で動作する「リゾルバ」（DNSクライアント）を「スタブ リゾルバ」と呼ぶ。 ***スレーブ サーバ [#ddb6cf73] また、「再帰クエリ」を他サーバへ転送し、自身は「反復クエリ」を送信しない「スタブ リゾルバ」機能だけを実装しているDNSサーバを俗に「スレーブ サーバ」と呼ぶ。 #ref(StubResolverAndSlaveServer.png,left,nowrap,スタブ リゾルバ、スレーブ サーバ) **条件付きフォワーダとスタブ ゾーン [#u09dfcd4] コンテンツ サーバがDNS クエリを処理する際、~ 「別のDNS サーバを紹介したり別のDNS サーバへDNS クエリを転送したりする機能」~ に「条件付きフォワーダ」と「スタブ ゾーン」がある。 -TechNet > スタブ ゾーンと条件付きフォワーダとの違い~ http://technet.microsoft.com/ja-jp/library/cc780434.aspx ***条件付きフォワーダ [#uda932eb] -内部ドメイン（イントラネット）で名前解決できないDNSクエリなどを、~ 外部ドメイン（インターネット）に転送する場合、「条件付きフォワーダ」を定義してDNSクエリを転送する。 -「条件付きフォワーダ」では、特定のドメイン名に基づいてDNSクエリを転送することもできる。また、転送先のDNSサーバを「フォワーダ」と呼ぶ。 #ref(Conditionalforwarder1.png,left,nowrap,条件付きフォワーダ（１）) -企業の合併により、2つの異なる内部ドメイン（イントラネット）で、~ 名前解決が必要になる場合などにも、この「条件付きフォワーダ」が利用できる。 #ref(Conditionalforwarder2.png,left,nowrap,条件付きフォワーダ（１）) ***スタブ ゾーン [#ta72a3a7] -「委任」では、親ドメインの管理者は子ドメインのゾーン データをホストするコンテンツ サーバのFQDN名とIPアドレスの~ [[リソースレコード>#yade5685]]を手動で管理する必要があるが、「スタブ ゾーン」を利用することで、この管理を自動化できる。 -「スタブ ゾーン」には、子ドメインのマスタ サーバ のIPアドレスを持つ[[リソースレコード>#yade5685]]が含まれており、~ 子ドメインのマスタ サーバと通信することで最新のゾーン データを取得できる。 -マスタ サーバは、 --子ドメインの「[[プライマリ ネームサーバ>#g91220a5]]」 --または「[[セカンダリ ネームサーバ>#xc525b5b]]」 >である。 これにより、「スタブ ゾーン」をホストする親ドメインの「コンテンツ サーバ」では、子ドメインの管理を自動化できる。 #ref(StubZone.png,left,nowrap,スタブ ゾーン) また、「スタブ ゾーン」をホストする親ドメインのコンテンツ サーバが、子ドメインに対するDNSクエリを受信した場合、次のような処理を実行する。 -再帰クエリの場合~ 親ドメインのコンテンツ サーバは「スタブ ゾーン」の[[リソースレコード>#yade5685]]を使って、子ドメインのコンテンツ サーバに「反復クエリ」を送信する。 -反復クエリの場合~ 親ドメインのコンテンツ サーバは「スタブ ゾーン」の[[リソースレコード>#yade5685]]を使って、子ドメインのコンテンツ サーバへの紹介を返す。 **BBルータを使用した家庭LANの例 [#na9fd308] 例えば、家庭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の名前解決の流れ、自分用まとめ - cigiの日記~ http://d.hatena.ne.jp/cigi/20130914/p1 *ゾーン [#e4aa5e9b] 各ノードで管理されるDNS情報の単位を「ゾーン」と呼ぶ。 -「ゾーン」は、1個から複数個のドメインの情報を記載する。 -「ゾーン」が複数のDNSサーバに跨って保持されることは無い。 **前方参照ゾーン・逆引き参照ゾーン [#o3e5fe46] ***前方参照ゾーン [#lecf5571] -「前方参照ゾーン」とは、DNSによる正引き名前解決に必要なゾーン データであり、必ず作成する必要がある。 -一般的にコンテンツ サーバのドメイン ツリー構造といった場合、「逆引き参照ゾーン」のツリー構造を指す。 ***逆引き参照ゾーン [#u25f8211] DNSによる逆引き名前解決に必要なゾーン データである。 -「前方参照ゾーン」のコンテンツ サーバのドメイン ツリーとは別に、~ 「逆引き参照ゾーン」のコンテンツ サーバのツリーも存在する。 -ルート ネーム サーバは共通のコンテンツ サーバになっている。 -「逆引き参照ゾーン」のトップ レベル ドメインとセカンド レベル ドメインは、「.in-addr.arpa」という特別な名前が付けられている。 -セカンド レベル ドメイン以降のドメイン名は、検索の基になるIPアドレスの各オクテットを逆順に並べたものになる。 -例えば、「zzz.yyy.xxx.vvv」というIPアドレス（仮にクラスCのIPアドレスとする）のホストは、「arpa.in-addr.xxx.yyy.zzz」というゾーンに格納される。~ クラスレス アドレッシング（CIDR）が適用された環境化では、この限りではない。 #ref(Zone.png,left,nowrap,前方参照ゾーン・逆引き参照ゾーン) ***スタブ ゾーン [#u3ed5a36] 「スタブ ゾーン」については、「[[スタブ ゾーン>#ta72a3a7]]」で説明。 **ゾーン レコード [#yade5685] ゾーン データの単位を「レコード」、「リソース レコード」と言う。 ***A（Address）リソースレコード [#e376de24] IPv4アドレスからFQDNを調べる。 |FQDN|TTL|Class|Type|IPアドレス|h |www.example.com.|1D|IN|A|xxx.xxx.xxx.xxx| ***AAAAリソースレコード [#e09bc16d] IPv6アドレスからFQDNを調べる。 |FQDN|Class|Type|IPアドレス|h |www.example.com.|IN|AAAA|ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff| ***CNAME（Canonical NAME）リソースレコード [#pae30b43] Aレコードの別名を追加（≒ 別名に対する正式名を指定） |別名（FQDN|TTL|Class|Type|正式名（FQDN|h |www2.example.com.|1D|IN|CNAME|www.example.com.| ***NS（Name Server）リソースレコード [#i720ab0f] 該当ドメインのゾーンの権威を持つDNSサーバのFQDNを指定する。 |ゾーン名|TTL|Class|Type|DNSのFQDN|h |example.com.|1D|IN|NS|ns1.example.com.| ***SOA（Start Of Authority record）リソースレコード [#e14122ac] [[ゾーン>#e4aa5e9b]]に関する特定のauthoritative情報。 |ドメイン|TTL|Class|Type|マスターサーバ|メールアドレス|h |example.com.|1D|IN|SOA|ns.example.com|root.example.com.| -プライマリネームサーバ -ドメイン管理者の電子メール -ドメインのシリアル番号 -ゾーンのリフレッシュに関連するいくつかのタイマー ***MX（Mail eXchange）リソースレコード [#t9b45fa4] メアド用ドメインに対応するメールサーバのFQDNを指定する。 |メアド用ドメイン|TTL|Class|Type|プリファレンス値|メールサーバのFQDN|h |example.co.jp.|1D|IN|MX|10|mail.example.co.jp.| ***PTR（Canonical NAME）リソースレコード [#m317654c] 逆引き専用のリソースレコード |逆引きドメイン|TTL|Class|Type|正式名（FQDN|h |10.1.168.192.in-addr.arpa.|1D|IN|PTR|www.example.com.| ***TXT（Text）リソースレコード [#tcb8bd16] ドメインのコメントを調べる。 |ドメイン|Class|Type|コメント|h |example.co.jp.|IN|TXT|www.example.com.| ※ 最近は、[[SPF>#mb5fb38e]]など機械可読データに利用されるようになった。 ***SPF（Sender Policy Framework）リソースレコード [#mb5fb38e] メール送信元ドメインの許可された送信元を調べる。 |ドメイン|Class|Type|コメント|h |example.co.jp.|IN|TXT|www.example.com.| ※ [[TXT（Text）リソースレコード>#tcb8bd16]]を流用する。 ***OPT（Option）疑似リソースレコード [#la8a3342] -EDNS0により定義される、特殊なリソースレコード -DNSをDNSSECやIPv6に対応させる場合、EDNS0への対応が必須とされている。 ***参考 [#ja037a46] -俺のDNS - BIND9の覚書 - Qiita~ https://qiita.com/Ogaaaan/items/c8205d7b04a0f62a438f -TechNet > リソース レコード リファレンス~ http://technet.microsoft.com/ja-jp/library/cc758321.aspx -DNSレコードタイプの一覧 - Wikipedia~ https://ja.wikipedia.org/wiki/DNS%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%89%E3%82%BF%E3%82%A4%E3%83%97%E3%81%AE%E4%B8%80%E8%A6%A7 *DNSサーバの冗長化構成 [#l0d1a189] **プライマリ ネームサーバ・セカンダリ ネームサーバ [#of70c39d] -コンテンツ サーバには、冗長構成を組む時のために、 --「プライマリ ネームサーバ」 --「セカンダリ ネームサーバ」 >の区分けがある。 -コンテンツ サーバは、冗長化による可用性の向上を要求されることがある。 --例えば、インターネット上のjpドメインを管理するコンテンツ サーバは、~ 社団法人日本ネットワークインフォメーションセンター（JPNIC）の方針で、~ 2台のコンテンツ サーバを使い冗長化することが要求される。 -この冗長化の方式に --「プライマリ ネームサーバ」のゾーン データ（プライマリ ゾーン）を、~ --「セカンダリ ネームサーバ」のゾーン データ（セカンダリ ゾーン）に~ --レプリケーションする「ゾーン転送」と呼ぶ方式がある。 ***プライマリ ネームサーバ [#g91220a5] 「プライマリ ネームサーバ」は、「ゾーン ファイル」を自身で保存する。 ***セカンダリ ネームサーバ [#xc525b5b] -「セカンダリ ネームサーバ」は、ネットワークを経由して「プライマリ ネームサーバ」の「ゾーン ファイル」をレプリケーションする。 -「セカンダリ ネームサーバ」は多くの場合、１台以上登録できる。 -「フルサービス リゾルバ」は --「プライマリ ネームサーバ」・「セカンダリ ネームサーバ」を区別しない。 --設定されている優先順位に合わせて、ネームサーバを選択し、 ---1つ目のネームサーバでうまく解決できなかった場合、 ---2つ目のネームサーバを使用する。 #ref(PrimaryAndSecondaryAndZoneTransfer.png,left,nowrap,プライマリ ネームサーバ・セカンダリ ネームサーバと、ゾーン転送) -また、類似した言葉に「優先DNSサーバ」・「代替DNSサーバ」があるが、 --これ自体が「フルサービス リゾルバ」（キャッシュ サーバ）であることもある。 --しかし、「優先DNSサーバ」・「代替DNSサーバ」と「プライマリ ネームサーバ」・「セカンダリ ネームサーバ」が対応しない場合もある。 **ゾーン データをレプリケーションする、ゾーン転送の仕組み [#mb37ff8c] ゾーン データをレプリケーションする、「ゾーン転送」の仕組みの仕組みは、以下の通りである。 +セカンダリ ネームサーバは、セカンダリ ネームサーバの「SOA」レコードに含まれる「更新間隔」が経過したら、「SOA要求」を送信する。 +プライマリ ネームサーバは「SOA要求」を受信し、プライマリ ネームサーバの「SOA」レコードに含まれる「シリアル番号」を、「SOA返信」として返信する。 +セカンダリ ネームサーバは「シリアル番号」を参照し、ゾーン ファイルが更新されていることを確認する~ （受信した「シリアル番号」が、自身の保持する「シリアル番号」より大きい場合、ゾーン ファイルが更新されていることを意味する）。 +ゾーン ファイルが更新されている場合、セカンダリ ネームサーバはゾーン ファイルの更新を確認し、「ゾーン転送要求」を送信する。 +プライマリ ネームサーバは「SOA要求」を受信し、ゾーン転送を開始する。この時、ゾーン転送の種類として「完全ゾーン転送 」・「差分 / 増分ゾーン転送 」を選択できる。 --「完全ゾーン転送」（AXFR） ---すべての DNS サーバにサポートされている標準的なレプリケート処理で、ゾーン ファイル全体が「プライマリ ネームサーバ」から「セカンダリ ネームサーバ」にレプリケートされる。 --「差分 / 増分ゾーン転送」（IXFR） ---「差分 / 増分ゾーン転送」では、転送量を減らすことができる。 ---「プライマリ ネームサーバ」のゾーンの変更履歴から、「セカンダリ ネームサーバ」のゾーン ファイルとの差分 / 増分情報のみがレプリケートされる。 ---「プライマリ ネームサーバ」が「差分 / 増分ゾーン転送」をサポートしないか、またはゾーンの変更履歴がない場合は、「完全ゾーン転送」でレプリケートされる。 +セカンダリ ネームサーバは、この転送データをもとに、自身のゾーン ファイルを 最新の情報に更新し、新しいゾーン ファイルを有効にする。 #ref(MechanismOfZoneTransfer.png,left,nowrap,ゾーン転送の仕組み) ※ゾーン転送は、 -一般的にはセカンダリ ネームサーバ側から要求がされる（プル型）。 -ただし、プライマリ ネームサーバからゾーン ファイルの更新をセカンダリ ネームサーバに「通知」することもできる（プッシュ型）。 -また、信頼性を確保するためプロトコルにはTCPを使用する。 *WindowsでのDNSクライアントの設定 [#vbb94494] 以下に、WindowsでのDNSクライアントを構成する場合の設定方法を示す。 **優先DNSサーバ・代替DNSサーバの設定方法 [#ncf76dcf] Windowsに「優先DNSサーバ」・「代替DNSサーバ」を設定する手順を以下に示す。 +[スタート] ⇒ [設定] ⇒ [ネットワーク接続] ⇒ [ローカルエリア接続]を右クリックし[プロパティ]を選択する。 +表示されたダイアログの[全般]タブで「インターネット プロトコル（TCP/IP）」を選択し、[プロパティ]ボタンを押す。~ これにより[インターネット プロトコル（TCP/IP）のプロパティ]ダイアログが表示される。 +[全般]タブのプロパティを設定することで、「優先DNSサーバ」・「代替DNSサーバ」のIPアドレスを設定できる。設定箇所には、以下の３箇所がある。 +++DHCPサーバから各DNSサーバのIPアドレスを取得する場合は、[DNSサーバのアドレスを自動的に取得する]オプション ボタンを選択する。 +++「優先DNSサーバ」・「代替DNSサーバ」の各IPアドレスを設定するには、[次のDNSサーバのアドレスと使う] オプション ボタンを設定し、DNSサーバのIPアドレスを直接入力する。 +++3台以上の「代替DNSサーバ」のIPアドレスを設定するには、~ [インターネット プロトコル（TCP/IP）のプロパティ]ダイアログの[全般]タブの[詳細設定]ボタンを押して表示される、~ [TCP/IP詳細設定]ダイアログの[DNS]タブの[DNSサーバー アドレス]リスト ボックスにDNSサーバのIPアドレスを設定する。 リストの上から順番に問い合わせるので、一番上が「優先DNSサーバ」になる。 #ref(HowToSetPreferredDNSAndAlternateDNS.png,left,nowrap,「優先DNSサーバ」・「代替DNSサーバ」の設定方法) **DNSの検索サフィックスの設定方法 [#b386c4f7] ***DNSの検索サフィックスとは [#w1ff0653] -ユーザがドメイン名を省略してホスト名だけでアクセスしようとした場合、DNSクライアント（リゾルバ）がホスト名から自動的にFQDN名を生成して名前解決をする。 -このFQDN名の生成処理は、DNSの検索サフィックスとオプションを変更することで動作を変更できる。 ***Windowsへの設定方法 [#t739476a] WindowsにDNSの検索サフィックスを設定する手順を以下に示す。 +[スタート] ⇒ [設定] ⇒ [ネットワーク接続] ⇒ [ローカルエリア接続]を右クリックし[プロパティ]を選択する。 +表示されたダイアログの[全般]タブで「インターネット プロトコル（TCP/IP）」を選択し、[プロパティ]ボタンを押す。~ これにより[インターネット プロトコル（TCP/IP）のプロパティ]ダイアログが表示される。 +[インターネット プロトコル（TCP/IP）のプロパティ]ダイアログの[全般]タブの[詳細設定]ボタンを押して表示される、~ [TCP/IP詳細設定]ダイアログの[DNS]タブにDNSの検索サフィックスを設定する。設定箇所には、以下の２箇所がある。 +++[プライマリおよび接続専用のDNSサフィックスを追加する]オプション ボタン~ こちらを選択することで、「プライマリDNSサフィックス」と「接続専用のDNSサフィックス」をFQDN名の生成処理に使用するようになる。~ 同時に[プライマリDNSサフィックスの親サフィックスを追加する]チェック ボタンを選択すると、~ 「プライマリDNSサフィックス」の親ドメインのDNSサフィックスを順番にFQDN名の生成処理に使用するようになる。 +++[以下のDNSサフィックスを順に追加する]オプション ボタン~ こちらを選択し、リスト ボックスにDNSサフィックスを入力することで、リストの上のDNSサフィックスを順番にFQDN名の生成処理に使用するようになる。 #ref(HowToSetDNSSuffixSearchList.png,left,nowrap,DNSの検索サフィックスの設定方法) **ローカルFQDN名生成の元情報の設定方法 [#jce16d30] WindowsにローカルPCのFQDN名を生成する元情報である -「プライマリDNSサフィックス」 -「接続専用のDNSサフィックス」 を設定する手順を以下に示す。 -「プライマリDNSサフィックス」 -「接続専用のDNSサフィックス」 は、DNSの検索サフィックスとしても使用される。 ここで設定した、DNSの検索サフィックスは、~ [[「ipconfig /all」コマンド>ipconfigコマンド]]を使用して確認できる。 ***プライマリDNSサフィックスの設定方法 [#f34f78a4] +[スタート] ⇒ [設定] ⇒ [コントロール パネル] ⇒ [システム]を選択し、[システムのプロパティ]ダイアログを表示させる。次に、[コンピュータ名]タブに移動し、[変更]ボタンを押す。 +すると、[コンピュータ名の変更]ダイアログが表示されるので、[詳細]ボタンを押す。これにより、[DNSサフィックスとNetBIOSコンピュータ名] ダイアログが表示される。 +「プライマリDNSサフィックス」は、ここの[このコンピュータのプライマリDNSサフィックス]に入力することで設定可能である。 #ref(HowToSetPrimaryDNSSuffix.png,left,nowrap,プライマリDNSサフィックスの設定) ***接続専用のDNSサフィックスの設定方法 [#ybabbe3c] +[スタート] ⇒ [設定] ⇒ [ネットワーク接続] ⇒ [ローカルエリア接続]を右クリックし[プロパティ]を選択する。 +表示されたダイアログの[全般]タブで「インターネット プロトコル（TCP/IP）」を選択し、[プロパティ]ボタンを押す。~ これにより[インターネット プロトコル（TCP/IP）のプロパティ]ダイアログが表示される。 +[インターネット プロトコル（TCP/IP）のプロパティ]ダイアログの[全般]タブの[詳細設定]ボタンを押して表示される、~ [TCP/IP詳細設定]ダイアログの[DNS]タブの下部のテキスト ボックスで設定できる。 #ref(HowToSetConnectionSpecificDNSSuffix.png,left,nowrap,接続専用のDNSサフィックスの設定) **ゾーン ファイルの動的更新の設定方法 [#v7a8c716] ***ゾーン ファイルの動的更新 [#r01fda3a] 下記に該当する場合に利用できる、そのホスト名とIPアドレスの対応を動的に登録・管理するための仕組みとして「ゾーン ファイルの動的更新機能」がある。 -DHCPサーバ（または、[[PPP]]のNCPプロトコル）から動的にIPアドレスが割り当てられる場合 -静的にIPアドレスを割り当てるが、頻繁に設定が変更される場合。 この「ゾーン ファイルの動的更新機能」に対応したDNSをDDNS（Dynamic DNS）という。 DDNSは、その用途・形態から大きく以下の2通りに分けることができる。 -イントラネット内の動的更新 --DHCPサーバから動的にIPアドレスが割り当てられたホストが、DNSサーバに対して直接、ゾーン ファイルを動的に更新する。 --このため、各ホストが「プライマリ ネームサーバ」を直接利用できる形態である必要がある。 -インターネット環境の動的更新 --FHHTなどの常時接続サービスにおいて、イントラネットで用いられるDDNSの発想を受けて、DDNSサービスが普及した。 ---[[PPP]]のNCPプロトコルから動的にIPアドレスが割り当てられたBBルータが、DNSサーバに対して、ゾーン ファイルを動的に更新する。 ---BBルータが動的更新機能を持たない場合、イーサネット上のホストから、専用のDDNSクライアント ツールを使用して定期的にゾーン ファイルを動的に更新する方法もある。 --DDNSクライアント ツール ---DiCE DynamicDNSクライアント ツールなどが有名である。 ---また、専用のHTMLフォームからゾーン ファイルを更新する機能を提供しているDDNSサービスもある。 ***Windowsへの設定方法 [#a6a0eccd] -Windows 2000以降のWindows OSでは、「ゾーン ファイルの動的更新」が有効になっている場合、~ システム起動時のNetBIOSの名前登録に加え、DNSサーバの「前方参照ゾーン」・「逆引き参照ゾーン」に対する名前登録も実行される。 -「ゾーン ファイルの動的更新」は、[TCP/IP 詳細設定]ダイアログの[DNS]タブの下部の、~ [この接続のアドレスをDNSに登録する] や [この接続のDNSサフィックスをDNS登録に使う]チェック ボックスで設定できる。 --前者の[この接続のアドレスをDNSに登録する]は、~ 「プライマリDNSサフィックス」を使用してDDNSにレコードを登録する。 --後者の[この接続のDNSサフィックスをDNS登録に使う]は、~ 「接続専用のDNSサフィックス」を使用してDDNSにレコードを登録する。 #ref(HowToSetDynamicUpdatesToZoneFiles.png,left,nowrap,ゾーン ファイルの動的更新の設定) -ただし、ゾーン ファイルの動的更新は --「優先DNSサーバ」が、「プライマリ ネームサーバ」であり、 --且つ動的更新をサポートする場合に限る。 --例えば、下記の動的更新をサポートしないDNSサーバを ---動的更新を無効にした「プライマリ ネームサーバ」 ---「セカンダリ ネームサーバ」 ---「フルサービス リゾルバ」（キャッシュ サーバ） ---「スレーブ サーバ」 >「優先DNSサーバ」に設定した場合、 --DNSクライアントの「ゾーン ファイルの動的更新」を有効にすると、 ---無駄なトラフィックを発生するだけでなく、 ---サーバのログに大量のエラーが記録されることもある。 *DNSサーバの診断ツール [#ccbfc75a] **[[nslookupコマンド]] [#ofb80638] ***DNSクライアントの名前解決機能を手動実行する。 [#k490fa65] -「nslookup」コマンドを使用すると、DNSクライアントの名前解決機能を手動実行できる。その他にも、各レコードの情報を検索できる。 -例えば、DNSクライアントから次のコマンドを実行すれば、DNSサーバに登録されているサーバのFQDN名をIPアドレスに名前解決できる。 C:\dnslint>nslookup Default Server: （DNSサーバのFQDN名） Address: （DNSサーバのIPアドレス） >（任意のサーバのFQDN名） Server: （DNSサーバのFQDN名） Address: （DNSサーバのIPアドレス） Name: （任意のサーバのFQDN名） Address: （任意のサーバのIPアドレス） ***ゾーン レコードをテキスト ファイルに出力する。 [#kcdbe1df] -「nslookup」の「ls」コマンドを実行すれば、DNSサーバに登録してある任意のドメインのゾーン レコードをテキスト ファイルに出力できる。 --「nslookup」の「ls」コマンドは、「完全ゾーン転送」と同様の動作になる。 --また、「ls」コマンドが正常に完了するには、コマンドを実行しているマシンのIPアドレスが、ゾーン転送先として許可されている必要がある。 C:\>nslookup Default Server: （DNSサーバのFQDN名） Address: （DNSサーバのIPアドレス） > ls -d （任意のドメイン名） > result.txt [（DNSサーバのFQDN名）] ###### Received 335 records. > exit ***参考 [#z0720db0] -マイクロソフト サポート オンライン > NSlookup.exe の使用方法~ http://support.microsoft.com/kb/200525/ja -＠IT > Master of IP Network > nslookup - DNSサーバに名前解決の問い合わせを行う~ http://www.atmarkit.co.jp/fnetwork/netcom/nslookup/nslookup.html -Linuxの将来のバージョンのDNSでは --「nslookup」コマンドが廃止され、その代用として「dig」コマンドや「host」コマンドが採用される。 --また、BIND9など「nslookup」の「ls」コマンドが使用できないDNSサーバもある。 **[[DNSListコマンド]] [#z89e5ac8] 「DNSLint」というコマンド ライン診断ツールを使用して、DNSクエリを検証できる。 -例えば、次のようなクエリ ファイル（input.txt）を用意して DNSLint [dns~server] （DNSサーバのFQDN名） （サーバAのFQDN名）,a,r （サーバBのFQDN名）,a,r -次のコマンドを実行すれば、DNSクエリを検証できる。 >dnslint.exe /ql input.txt /v verifying input file...input file looks valid... processing file... processing DNS queries... DNS server: （DNSサーバのIPアドレス） =========== querying for （サーバAのFQDN名） record type: A query type: recursive Query result: Match found （サーバAのIPアドレス） querying for （サーバBのFQDN名） record type: A query type: recursive Query result: Match found （サーバBのIPアドレス） Creating report called dnslint.htm in current directory -出力される、dnslint.htmには以下のような情報が記録されている。 #ref(dnslint.png,left,nowrap,DNSLintのHTML レポート) -参考 --マイクロソフト サポート オンライン > DNSLintユーティリティについて~ http://support.microsoft.com/kb/321045/ja **[[ipconfigコマンド]] [#a58a3cfc] *参考 [#l60d535a] -Insider's Computer Dictionary [DNS] － ＠IT~ http://www.atmarkit.co.jp/icd/root/23/5786923.html -＠IT総合トップ > Master of IP Network --DNSの仕組みを学ぼう！~ http://www.atmarkit.co.jp/fnetwork/rensai/ad04/ad01.html --DNSの仕組みの基本を理解しよう~ http://www.atmarkit.co.jp/fnetwork/rensai/dns01/dns01.html -Active Directory管理者のためのDNS入門 伊藤 将人~ http://www.atmarkit.co.jp/fwin2k/operation/indexpage/index.html#addns --第1回 DNSの基礎知識~ http://www.atmarkit.co.jp/fwin2k/operation/addns01/addns01_01.html +++DNSの仕組み +++Active Directory用のDNS --第2回 Windows DNSサービスのインストール~ http://www.atmarkit.co.jp/fwin2k/operation/addns02/addns02_01.html +++DNSサービスのインストール前の準備 +++DNSサービスのインストール（1） +++DNSサービスのインストール（2） +++Active Directory用DNSのインストールと構成 ---- Tags: [[:IT国際標準]], [[:Active Directory]], [[:認証基盤]], [[:ディレクトリ サービス]]
