仕組みとは？
|
ClickOnceテクノロジには、これまで登場してきたさまざまな展開テクノロジの良いところが積極的に取り入れられつつ、さらにマイクロソフト流の使いやすさと機能性が追加されている。 このClickOnceテクノロジを詳しく調べていくにつれ、ClickOnceに対する筆者の印象は以前よりもかなり良くなった。というのもClickOnceには、アプリケーション配布時や更新時のパフォーマンスを高めるための仕組みが搭載されていたり、運用時の細かなニーズに対応するための拡張性・自由度が備わっていたりするなど、実際の開発／運用の場面で起こりやすい問題への対処が最初からきちんと考慮されていることが分かったからだ。 本連載では、そのような「ClickOnceのどこが優れているのか」、また逆に「どこがいまいちなのか」、つまりClickOnceの真実が伝わる内容にしていきたいと考えている。 さて、前回ではClickOnceの基本動作や基本機能についてユーザーの視点でお伝えしたが、今回以降では下に示す目次のタイトルの内容を順次解説していく予定だ。 今回は、恐らく読者が最も興味を持っているであろうClickOnceの動作原理について、システム管理者およびシステム開発者の視点で詳しく説明する。まずはClickOnceアプリケーション（ClickOnceアプリ）を配布する際の流れから説明していこう。 ClickOnceの配布の仕組みについてさっそく説明していきたいわけだが、その前に前提知識として理解しておいてほしい「配布時のオプション（＝配置オプション）との関係」を手短にまとめたので、まずはこれにざっと目を通していただきたい。 ClickOnceでは、配置時のオプションとして、アプリケーションを配布（＝デプロイメント）する方法を、次の2種類から選択できる。 これらのモードは、ClickOnceでは「インストール・モード」と呼ばれ、アプリケーションをユーザー環境にインストールしてオフラインでも実行可能にするか（1）、オンラインからの直接実行しかできないようにするか（2）、を決めるためのものである（インストール・モードの詳細は次回で詳しく説明する予定なので、ここでは割愛する）。 このようにいうと、（2）のネットワーク上から起動するモードは、従来のノータッチ・デプロイメントと同じ仕組みが使われていると思われる読者諸氏も少なくないかもしれないが、それは誤解である。 実はClickOnceのデプロイメント機能では、（1）のモードでも（2）のモードでもほとんど同じ仕組みが使われているのだ。そこで大きく違う点といえば、それがローカル環境からのオフライン実行が許されているか（1）、許されていないか（2）というアプリケーション実行段階での制限の違いにすぎない。 またClickOnceでは、配置オプションとして、配布するアプリケーションを置いておく場所を、次の3種類から選択しなければならない。 これらの場所の選択肢は、ClickOnceでは「配置場所」（開発者の視点でいえば「発行場所」）と呼ばれ、アプリケーションの利用形態やユーザー層に合わせた配布経路を選択するためのものだ（詳細は次回解説）。 この配置場所も先ほどと同様に、どれを選択したところで、ClickOnceでアプリケーションをデプロイメントする際の基本的な仕組みは変わらない。 以上をまとめると、ClickOnceではインストール・モードと配置場所など多彩な配置オプションが提供されているが、どのオプションを選択しようがアプリケーション配布時の基本的な仕組みは同じであるということだ。オプションを切り替えることで、配布メカニズムが大きく変化するわけではないということを、知っておいていただきたい。 前置きが少し長くなってしまったが、それでは肝心のClickOnceによるアプリケーション配布の流れを説明しよう。 VS 2005の発行機能を利用すると、配布用のClickOnceアプリのフォルダ（この例では「SampleApplication」）が任意の発行場所（この例では、IISが管理する「C:\Inetpub\wwwroot」配下）に自動作成される。なお前述したように、フォルダの内容は、どのインストール・モード、どの発行場所を選択してもほぼ同じになる（詳細次回）。 ユーザー環境に配布するアプリケーションの実体（本稿の例では、SampleApplication.exe.deployファイル）などを格納するフォルダ。フォルダ名の命名規則は「＜アセンブリ名＞_＜発行バージョン＞」で、この例では「SampleApplication_1_0_0_0」となっている（ちなみに「発行バージョン」の設定などについては次回で説明）。 プログラムの実体。「SampleApplication.exe」というファイル名に「.deploy」というサフィックス（拡張子）が付いているのは、セキュリティ上の観点から「.exe」「.dll」「.config」などの拡張子を持つファイルへの要求を制限しているWebサーバに対応するためである。Webサーバ上に配置しないケースで、.exeファイルを直接実行したいという要望がある場合では、.deploy拡張子を付けないようにすることもできる（詳細次回）。 アプリケーション・マニフェスト（.manifestファイル）。配布するClickOnceアプリ自体に関する情報を記述したマニフェスト・ファイル（詳細後述）。 ClickOnceアプリのインストールや実行を促すためのWebページ（参考：前回の「VS 2005で生成されたClickOnceアプリ・インストール用のWebページ」）。 メインとなる配置マニフェスト（.applicationファイル）。ClickOnceアプリの配布・更新に関する情報を記述したマニフェスト・ファイル（詳細後述）。.NET Framework 2.0がインストールされている環境で、この.applicationファイルが実行されると、ClickOnceアプリのインストールや起動が開始されるのだが、その仕組みは後述する。また、ClickOnceアプリの更新チェックにもこのファイルが参照される。 配置マニフェストのバージョンごとのバックアップ。緊急時などでの配置マニフェストと置き換えてClickOnceアプリのバージョンをダウンさせるときのためのバックアップ。 セットアップ・ファイル。基本的な用途は、アプリケーションを実行するための要件となる必須コンポーネントをインストールすること。なおこのファイルを実行しても、最終的には.applicationファイルが実行されるので、結局、ClickOnceアプリのインストールや実行が行える。 この図の中で、ClickOnceアプリが配布されるために最も重要なファイルは、のSampleApplication.applicationファイルである（.applicationファイルは「配置マニフェスト」もしくは「デプロイメント・マニフェスト」と呼ばれる。詳細については本稿最後でまとめた）。このファイルが、ClickOnceアプリをインストール／実行する際のエントリ・ポイントといってもよい。 実際に本稿の例のVS 2005の配布機能によって生成されたClickOnceアプリ・インストール用のWebページの［インストール］ボタン（＝ClickOnceアプリのインストール／実行はここから始まる）は、このSampleApplication.applicationファイルにリンクされている*1。 *1 アプリケーションを実行するための要件となる必須コンポーネントがインストールされていないような環境では、のsetup.exeファイルにリンクが張られることがある。これはsetup.exeによって、アプリケーション実行の要件となる必須コンポーネントをまずインストールさせるためだ。本稿の例では、.NET Framework 2.0がインストールされていない環境でClickOnceアプリ・インストール用のWebページ（参考：前回の「ClickOnceが提供する.NET Framework 2.0インストール用のWebページ」）の［インストール］ボタンをクリックすると、setup.exeが実行されて、実際のClickOnceアプリをインストールする前に、.NET Framework 2.0のランタイムがインストールされる。ちなみにアプリケーション要件が満たされている状態でこのsetup.exeを直接実行しても、最終的にはSampleApplication.applicationが実行されてClickOnceアプリのインストールや実行が行われる。 次の図は、エントリ・ポイントとなるSampleApplication.application（配置マニフェスト）の実行からClickOnceアプリが配布、実行されるまでの流れを図示したものだ。 エントリ・ポイントとなるSampleApplication.application（配置マニフェスト）の実行からClickOnceアプリが実行されるまでの流れを図示したものだ。各番号の説明は以下の本文にある。 ※この画像をクリックして別ウィンドウで表示しながら以下の説明を読むと便利だ。 *2 ちなみにWebサーバはIISを使ったWindowsサーバである必要はない。ClickOnceアプリは、Linux＋ApacheなどのWebサーバ上からも実行できる。ただし、実際にClickOnceアプリをWebサーバに配置する際には、いくつかの注意点があるが、これについては次回解説する。 dfsvc.exeはClickOnceの実行エンジンそのもの（以降、ClickOnceローダー）で、主にClickOnceアプリの最新バージョンをチェックして、必要ならダウンロードし、ClickOnceアプリを起動するという役割を持っている。 *3 .NET Framework 2.0をインストールした環境で、Internet Explorer（以降、IE）により.applicationファイルにアクセスすると、適切なMIMEタイプもしくは拡張子のハンドリングが行われるが、そのほかのWebブラウザではほぼうまく処理されないようだ。従って現状では、ClickOnceの実行にはIEが不可欠といえるだろう。 ClickOnceローダーは、配置マニフェスト（.applicationファイル）を読み込み、内容を解析する。その解析結果から、ClickOnceアプリのバージョンやアプリケーション・マニフェスト（SampleApplication.exe.manifestファイル）の場所*5などの情報を特定する。 *5 アプリケーション・マニフェスト（.manifestファイル）の場所についての情報は、配置マニフェストの<dependentAssembly>要素のcodebase属性から得られる。ここには例えば次のような内容が記述されている。 次に、アプリケーション・マニフェスト（SampleApplication.exe.manifest）を読み込んで解析して、そこでダウンロードすべきアセンブリやファイルを決定する。 実際にそれらをダウンロードする前に、ユーザーに対してそのアプリケーションをインストール／実行してもよいかどうかを尋ねるためのセキュリティ警告を表示する。ここで［インストールする］を選択してインストール／実行を許可すると、.NET Framework 2.0が持つ「信頼されたアプリケーション」の一覧にそのClickOnceアプリが登録され、次回以降のここでのセキュリティ警告はスキップされるようになる（このあたりのセキュリティの仕組みは次回以降で説明する） そして実際に、ユーザーごとに存在する「C:\Documents and Settings\＜ユーザー名＞\Apps\2.0」配下のアプリケーションごとのClickOnceキャッシュ領域（「ClickOnceアプリケーション・ストア」とも呼ばれる）*6にClickOnceアプリをダウンロードする（つまり、ClickOnceアプリのインストールは、同一マシン上であっても常にユーザーごとに行う必要があるということだ）。 *6 ClickOnceキャッシュ領域は、従来のノータッチ・デプロイメントが利用する.NETアセンブリ・ダウンロード・キャッシュ領域とはまったく異なる場所だ。ClickOnceアプリは、（1）ローカル環境へインストールするモードや（2）ネットワーク上から起動するモードなどのインストール・モードの違いによらず、常にこのClickOnceキャッシュ領域に格納されることになる。（2）ネットワーク上から起動するモードの部分信頼のClickOnceアプリに対しては、ClickOnceキャッシュ領域はデフォルトで250MBytesが割り当てられている（なお、（2）のモードの完全信頼のClickOnceアプリや（1）のモードでは、この制限はない）。この領域サイズの制限は、純粋なアプリケーション群のサイズに対するもので、データ・ファイルは含まれない。 ちなみにClickOnceでは、＜1つ前＞と＜現在＞の2つのバージョン分のClickOnceアプリしか、このClickOnceキャッシュ領域に保持しない。このため、1つだけバージョンをロールバックさせられるのだが、それより前のバージョンにはロールバックできない。 次の処理は、ダウンロードしたClickOnceアプリが、完全信頼（Full Trust）アプリケーションなのか、部分信頼（Partial Trust）アプリケーションなのかによって、条件分岐する。 一方、部分信頼アプリケーションの場合、実行ファイルではなく「AppLaunch.exe」が起動される*7。AppLaunch.exeはClickOnceアプリをホスティングするためのプログラム（以降、ClickOnceホスト）で、具体的には、コード・アクセス・セキュリティの制限がかかったアプリケーション・ドメイン（AppDomain）を作成して、そのアプリケーション・ドメインの中にClickOnceアプリのプライマリ・アセンブリをロードし、そのアセンブリのマネージ・コード上のメイン・エントリ・ポイントを呼び出す。これによりClickOnceアプリは部分信頼状態で実行が開始される。 以上が一連のClickOnce配置の仕組みだ。なおClickOnceローダー（dfsvc.exe）はアプリケーションを終了しただけでは終了せず、およそ15分間何も実行されない状態が続くと自動的に終了するようになっている。 【2006/7/19】本記事の一部に以下のような誤りがありました。お詫びして訂正させていただきます。 （2）ネットワーク上から起動するモードのClickOnceアプリに対しては、ClickOnceキャッシュ領域はデフォルトで250MBytesが割り当てられている（なお、（1）インストールするモードではこの制限はない）。 （2）ネットワーク上から起動するモードの部分信頼のClickOnceアプリに対しては、ClickOnceキャッシュ領域はデフォルトで250MBytesが割り当てられている（なお、（2）のモードの完全信頼のClickOnceアプリや（1）のモードでは、この制限はない）。 Google対抗？ Microsoft Sync Frameworkの正体 （2007/11/20） 先日、マイクロソフトが発表した同期フレームワークは、.NETアプリケーションに何をもたらすのか？ 実装サンプルを通して、その機能と特徴を簡単に紹介 技術者としての力量を数値で把握していますか？ITSSレベルを無料で判定、12月25日（火）まで ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン ＠ITトップ｜VB業務アプリケーション開発研究室 トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ |
[ 201] ClickOnceの仕組みを理解しよう − ＠IT
[引用サイト] http://www.atmarkit.co.jp/fdotnet/clickonce/clickonce02/clickonce02_01.html
|
いきなりだが、2001年はDNS（Domain Name System）にとっては、当たり年ともいえる年だった。ニュースなどでも取り上げられているが、「日本語」や「多言語」ドメインという大きな構造変化がシステム全体に押し寄せ、ブロードバンド環境の広がりは、個人がドメインを取得して運用するための足掛かりともなった。 本連載では、ドメインの運用など、これからDNSと付き合おうとしている方々を対象に「DNSの概念や運用の考え方」を明らかにしていこう。ただし「BIND」など、DNSに関する具体的な製品の設定方法については触れない。詳しくは以下の記事もぜひ参考にしてほしい。 まず最初に、「DNSとは何か」を説明するために、「なぜDNSが必要になるのか」を考えてみよう。それには、歴史的経緯から考えるのが分かりやすい。 DNSはご承知のとおり、IPアドレスとホスト名をマッピングして相互解決するための仕組みだ（これを「名前解決」と呼ぶ）。IPアドレスは単に数字でしかないので、さまざまなホストを管理したり、アプリケーションから特定のホストを指定するには、人間にとって理解しやすい「名前」の方が便利だ。 DNSと同じように、IPアドレスとホスト名のマッピングを行う最も原始的な仕組みが「hosts」ファイルだ。各ホストがローカルファイルとしてマッピング情報を管理している。Linuxでは「/etc/hosts」、Windows hostsファイルは、インターネットの前身であるARPANETで生まれた、一番最初の「名前解決」サービスだ。現在でも、小規模なネットワークでは有効な方法だ。非常に単純な対照表で運用も設定も楽だが、登録されるホスト名が増えれば逆に非効率的な仕組みであることも、直感的に理解してもらえるだろう。hostsファイルは、各ホストごとに設定しなくてはならないし、そもそも各ホストで同じ名前で設定できているという保証もない。 ARPANETにおいても、ネットワークに接続されたホストが数百を超えたあたりから運用の限界に達した。そこで考案されたのがDNSであり、1984年より実際に運用が始まった。hostsファイルのような対照表を管理する専用サーバ＝DNSサーバ（ネーム・サーバ）に情報を集約して、名前解決が必要なクライアントやアプリケーションから問い合わせをさせよう、という発想である。これにより、データ管理はDNSサーバだけで行えばよいことになる。だが、単にhostsファイルをそのままサーバへ移行するだけでは問題も残る。 例えば、たった1つのDNSサーバだけで全世界に存在する数百万以上のホスト情報を処理するのでは負荷に耐えられないだろうから、複数サーバによる運用は当然必要となる。だが、それらで完全に同じデータを持ち合うのでは、非常に非効率的だ。インターネットに接続する組織で、（当時は考えもしなかっただろうが）全世界に存在する数百万以上のホスト情報を保持しないといけないとしたら、これはかなりの負担だ。 また、「ホスト名のユニーク性」という問題もある。もしホスト名を付ける場合に、数百万ものホストが登録されたデータに対して、手動でユニーク性を確認しなければならないとしたらどうだろう。最も効率的なのは、ある種のホスト命名規則を用いて、ユニーク性を保証することだ。 普段使用される「DNS名（ドメイン名）」などと呼ばれるホスト名は、「.（ピリオド）」でいくつかの階層に区切られる。それぞれの階層ごとに、それ以下に含まれる下位ドメイン名やホスト名を管理するという「分散型」サービスとなっている。 このツリーの「枝分かれ」部分に該当するのが、いわゆる「ドメイン」である。「atmarkit.co.jp」など、上位ドメイン名を付けたものと区別するために「ノード」などとも呼ばれる。また、このようなデータ構造を含む名前を「名前空間（ネーム・スペース：Name 自身の下位ドメイン（サブドメイン）として何があるのか。そのサブドメインの情報を持っているDNSサーバは何か などの情報が管理される。これらを管理しているのが、それぞれのノードに位置して、そのドメインを管理するDNSサーバである。 ドメインのレベルによっては、主にサブドメイン情報のみを管理するサーバもあるかもしれないし、ホストしか管理していないサーバもあるだろう。だが、それぞれのDNSサーバの挙動や役割は、大きくは変わらない。 基本的に、各ノードに位置するDNSサーバでは、自身の管理するドメイン内情報とサブドメインのDNSサーバ名しか知らない。そこで、DNSへの問い合わせ側（DNSクライアントのことだが「リゾルバ」などとも呼ばれている）は、この階層を上位から順にたどっていけばよい。ルートからjpドメインのDNSサーバへ、jpドメインのDNSサーバはcoドメインのDNSサーバを知っているので、次にcoドメインのDNSサーバへatmarkit.co.jpドメインのDNSサーバを尋ねる。そして最終的には、「www.forum.atmarkit.co.jp」のIPアドレスを知るDNSサーバ（ここではforum.atmarkit.co.jpドメインのDNSサーバ）までたどり着けるだろう。 一見、非常に煩雑に見えるかもしれない。だがこのようにデータが配置できれば、各ノードで分散して情報を保持できるし、あるノードにおいて「host1」というホストを登録しても、ノード内のユニーク性さえ保証すれば、ドメイン名をホスト名に付加することで＊1、自動的にユニーク性が保証される。実は、非常に効率的かつ柔軟なシステムなのである。すなわちDNSとは、全世界に張り巡らされた「分散協調型データベース・システム」なのだ。 また、こうした運用を行ううえで、上位ドメイン（ノード）はサブドメイン（ノード）のDNSサーバ情報のみを保持しており、そのサブドメイン以下の情報についてはまったくタッチしていない。つまり、サブドメインを完全に信頼して、サブドメイン以下の定義（さらにどのようなサブドメインが含まれるか、どのようなホストが含まれているかなど）は、そのサブドメインに任せてしまうことになる。実は、1台のDNSサーバで自身のドメインと、そのドメインのサブドメイン情報をも管理してしまうことは可能なのだが、この場合、サブドメインの情報の管理は、別のDNSサーバに任せてしまうわけだ。 なぜか？ 例えば、一度組織にドメインが割り当てられてしまえば、そのドメインでどのようなサブドメインを作ろうと、ホスト名を登録しようと、完全に自由だ。ドメイン以下のことはそれぞれの組織に任せてしまった方が、管理効率は向上するからだ。これを、上位ドメインからサブドメインに対する「権限委譲（delegation）」と呼ぶ。権限委譲とは、自身から別のDNSサーバへその部分の管理権限を委譲する、という意味である。すなわち、ドメイン・ツリーは世界中の無数のDNSサーバをつなぐ「信頼の連鎖」ツリーでもあるのだ。 皆さんの組織のドメインも、必ずどこかの上位ドメインから権限委譲されている。例えば、atmarkit.co.jpドメインは、co.jpドメイン（を管理するDNSサーバ）から管理権限を委譲されている。詳しくは本連載の第2回以降で説明するが、各組織のDNSサーバをインターネット上に立ててドメイン情報を登録し、上位ドメインでそのドメインへ権限委譲していることを登録して初めて、インターネットのコミュニティから皆さんの組織のドメインとホストが、DNS上の一員であることが確認できるのである。 Qualified Domain Name）だ。例えば、「www.atmarkit.co.jp」がFQDNで、「www」を単にホスト名と呼んで区別することがある。なお、厳密にはFQDNは一番右側に「.（ピリオド）」を付加して示す。この例では「www.atmarkit.co.jp.」となる。このピリオドは、ここがルート・ノードであることを示している。すなわち「絶対パス形式」名というわけだ。ピリオドがない場合には「相対パス形式」と考えられる。ただし、WebブラウザでFQDNを指定する場合などは、相対パスではあるものの、そのスタート・ポイントのデフォルト値はルート・ノードとされるため省略可能なのだ。ピリオド付きのFQDNを指定するのは、現実にはDNSサーバ設定時ぐらいしかない では、各ノードのDNSサーバではどのような情報が必要になるのだろうか。各ノードで管理されるDNS情報の単位を「ゾーン」と呼ぶ。ゾーンは、DNS管理から見た場合のデータ範囲だ。1台のDNSサーバで複数のドメイン（親ドメインとサブドメインなど）を含む単一のゾーン情報を管理している場合もあれば、1台のDNSサーバで複数のゾーンを管理している場合もある。つまり、1つのゾーンは必ずしもドメインや物理的なDNSサーバの単位と一致するわけではないのだが＊2、少しややこしいので、ここでは「“1ゾーン＝1ドメイン”を1台のDNSサーバで管理している」と考えてもらっていい。 ゾーンに含まれるデータの単位が「レコード」だ。まさしく表データの中の1つ1つの行だと思っていい。ただし、データの種類は多岐にわたり、行というイメージからは程遠いかもしれない。実は、ゾーンに登録されるレコードは、ホスト名とIPアドレスの情報だけではない。以下に、主なレコードの種類を紹介する。 ・シリアル番号―ゾーン転送時に情報が更新されているかどうか判断に用いられる（本連載の第3回参照）。数値が大きくなっていれば更新済みという意味だ。番号は任意だが、管理しやすいように通常は「年月日＋連番」などの書式が多く用いられている ・転送再試行時間（retry）―ゾーン転送に失敗した場合の再試行までの猶予時間を秒で指定する ・レコード有効時間（expire）―ゾーン情報を最新と確認できない場合の有効時間を秒で指定する ・キャッシュ有効時間（TTL）―このゾーン情報をキャッシュする場合の有効時間を秒で指定する ホストの追加情報。ホストのハードウェア・ソフトウェア（OS）情報を記述する 表1 主なDNSレコードの種類（こちらをクリックすると別ウィンドウで表の全体を表示します） まず「SOA（Start Of a zone Of Authority）」は、ドメイン定義を宣言するレコードだ。ドメインのDNSサーバ名のほか、主にゾーン情報としてほかのDNSサーバへ転送する際の管理情報などから構成されている。ゾーン転送については連載の第3回にて解説する予定なので、いまはドメインのヘッダ情報のようなものだと考えていてほしい。 NSレコードは、ドメインとそのドメインのDNSサーバを指定するレコードだ。このレコードによって、サブドメインの存在とそのDNSサーバへの権限委譲が確認できる。 次に、Aレコードがホスト名からIPアドレスを得るためのレコードだ。例えば、WebブラウザがユーザーにURLを入力されて、そのホスト名からIPアドレスを取得する場合は、DNSサーバに対してこのAレコード情報を返答するよう命令しているのである。 Aレコードなど、ホスト名をキーにしてIPアドレスといった付随情報を取得するDNS解決方法を「正引き」と呼ぶ。逆に、IPアドレスをキーにしてホスト名を得る方法を「逆引き」と呼んでいる。逆引きのためのレコードが「PTR」レコードだ。それぞれ背中合わせの同じような処理に見えるかもしれないが、DNSにおいてはまったく別のレコードに依存している、別々の処理である。 逆引きは何のために使われるのかと思われるかもしれないが、確かにそれほど必須というべきレコードではない。使用例を挙げると、Webサーバのログに記載されているIPアドレスをホスト名へ変換する場合などだ。しかし、そうした利用を想定しないのであれば、PTRレコードをいちいち設定するのは手間なので、クライアント・マシンなどでは登録が省かれることも多い。 という右辺がドメインになっているメール・アドレスに対して、転送元メール・サーバ（sendmailなどのMTA）は通常、atmarkit.co.jpドメインのDNSサーバからMXレコードを検索する。 そして、MXレコードからatmarkit.co.jpドメインの受信用メール・サーバ名を取得し、そのメール・サーバに対してメールを転送する。本来、メール・アドレスの右辺はメール・サーバ名そのものだったのだが、このようにDNSとの連携によって、ドメイン名を用いることもできる。 ＊2端的には、ゾーンの範囲はBINDなどの定義ファイル（ゾーン・ファイル）での単位を指している。そのファイルでどのように記載されているかによるのである では実際に、どのようにDNS解決が行われているのかを見てみよう。すでに述べたように、DNS解決はドメイン・ツリーに沿って行われる。例えば、「www.atmarkit.co.jp」というホスト名からIPアドレスの解決を行うには、最上位のjpドメインのDNSサーバに接続して、次にco.jpドメインのDNSサーバ名を知る必要がある。 だが、ちょっと待ってほしい。すでに問題が発生している。そもそもjpドメインのDNSサーバ名（またはそのIPアドレス）をどうやって知ればいいのだろうか。実をいえば、上の文章には多少ウソがある。jpドメインはドメインとしては最上位だが、DNSサーバのツリー構造においては、最上位では“ない”のだ。 もう一度、図1を見てほしい。ここの一番上に「ルート・ノード」というのがあることが分かるだろうか。つまり、トップ・レベル・ドメイン（TLD：Top Level Domain）の上位にルートと呼ばれる特別なノードが存在しているのだ。このノードの正体は「ルート・ネーム・サーバ」と呼ばれるDNSサーバだ。 ルート・ネーム・サーバは、全世界のDNS環境の最も頂点に位置するDNSサーバである。「.com」「.net」「.jp」など、最上位のトップ・レベル・ドメインのDNSサーバ情報を保持するDNSサーバだ。つまり、DNS問い合わせの「スタート・ポイント」であり、ここからすべての検索は開始される。このルート・ネーム・サーバを知らない限り、ドメイン・ツリーからの検索は不可能だ。逆にいえば、すべてのリゾルバは、このルート・ネーム・サーバの情報さえ最初に与えられれば、確実に必要とするレコードまでたどり着けることだろう。 DNS検索は、原則的にはこのルート・ネーム・サーバからまずスタートして、順に下位DNSサーバへの問い合わせを繰り返して、最終的に目的レコードまでたどり着くことになる。 図4で少し注意が必要なのが、図の右側に見えるDNSサーバの存在だ。これまで例として挙げてきた「atmarkit.co.jp」ドメインではないうえに、これまで説明してきた「自身のドメイン情報を提供する」DNSサーバとは位置付けが違うのを分かってもらえるだろうか。実は、このDNSサーバはリゾルバ（DNSクライアント）として動作している 例えば、「ns.atmarkit.co.jp」や上位のDNSサーバは、外部からの問い合わせに対応したり、ドメイン情報を管理するDNSサーバだ。だが、普段解決する情報は自身が管理しているゾーン情報だけで、ほかのドメインに関する問い合わせに対しては「知らない」とただ返答するだけだ。 これに対して「dns.example.com」は、ユーザーからの外部ドメインなどの情報問い合わせ要求を受け付けて、先ほど説明したようにルート・ネーム・サーバやそのほかのDNSサーバへ順に問い合わせを行い、DNS解決を最後まで行おうとする。 この違いは、実は問い合わせ方法にある。「dns.example.com」は、この例では「リカーシブ（Recursive：「再帰検索」と呼ばれる）」というタイプの問い合わせをユーザーから受け付けている。この場合、DNSサーバはDNS解決が完結するまでドメイン・ツリーをたどり、（ほかのサーバに対して）検索を行い、最終結果を返さなければならない。 一方、「ns.atmarkit.co.jp」が「dns.example.com」から受けたのは、「イテレイティブ（Iterative：「反復検索」と呼ばれる）」問い合わせだ。この場合、自身が管理しているゾーン情報にのみ返答し、ほかのサーバへ問い合わせを行うことはない。 多少ややこしいのだが、DNSサーバはこのように問い合わせ種類によって、まったく異なる動作を行う。ここでは、別サーバとして表現したが、組織によっては同一サーバで兼ねていることもある。 Resolver）」、「dns.example.com」へ要求を送るだけのDNSクライアント（多くの場合は、皆さんが使用しているクライアントPCやメール・サーバなど）を「スタブ・リゾルバ（Stub Resolver）」と呼んで区別している。また、スタブ・リゾルバ機能だけを実装しているDNSサーバ（俗に「スレーブ・サーバ（Slave Server）」と呼ぶ＊3）もある。DNS問い合わせを受け付けるが、自身では再帰検索を行わないで、別のフルサービス・リゾルバDNSサーバ（「フォワーダ」と呼ばれる）へそのまま検索を転送して、依頼をするサーバだ。社内のDNSサーバを階層的・多段的に配置したい場合などに使用されることがある。 このように、普段クライアントPCへ設定している「DNSサーバ」の項目は、多くの場合、実はマスタ・サーバではなく、フルサービス・リゾルバ用DNSサーバなのである。要するに、DNSサーバにはさまざまな機能が詰め込まれており、多様な使用方法があるということなのだが、技術書によっては、これらの違いは当然のこととして表されている場合も多い。最初は分かりにくいと思われるので、しっかりと把握して混乱しないようにしよう。 ＊3実は、スレーブ・サーバの正確な定義についてはバリエーションがあり、書籍やマニュアルなどによっても若干異なっている場合がある。特にBIND8関連では、セカンダリ・サーバ（連載の第3回にて解説予定）をスレーブ・サーバと呼ぶことも多い。これは、BIND8でのセカンダリ・サーバのための設定値に由来する。ただし、本連載では原理を単純化／区別して理解していただきたいため、純粋に「自身で再帰検索などは行わず、ほかのサーバへ転送して解決を依頼するサーバ」をスレーブ・サーバと定義するので、注意してほしい。ここにセカンダリ・サーバなどの機能の意味は含んでいない。必要な場合は別に明示する これまで説明したドメイン・ツリーによるドメイン検索は、正引き用の検索だ。つまり、SOAレコードやAレコード、MXレコードなどはこの検索経路をたどる。注意が必要なのは、逆引きのときのPTRレコード検索だ。つまり、PTRレコード検索の場合は、最初に与えられるのはIPアドレスなので、当然このようなドメイン・ツリーは検索できない。そこで逆引きのためには特別な「逆引き用ドメイン・ツリー」が用意されている。 考え方は完全に正引きと同じだ。ただし、トップ・レベル・ドメインとセカンド・レベル・ドメインは、「.in-addr.arpa」という特別な名前が付けられている。もちろん、それぞれのノードに該当するDNSサーバもちゃんと用意されている。ルート・ネーム・サーバは正引きと共通だ（一部提供しないルート・ネーム・サーバもあるようだ）。 ポイントは、それ以下のドメイン（ノード）部分で、検索の基になるIPアドレスを逆順に並べたものだ。つまり、IPアドレスの各オクテットを仮想的にノードと見なして、「第1オクテットを担当するDNSサーバ」→「第2オクテットを担当するDNSサーバ……」と順に検索を行う。このあたりの動作原理は、正引きのときと完全に同じだ。違うのは、DNSサーバが保持して管理しているデータの部分だけだ。 問題となるのは、このようなツリーを構築してDNSサーバで管理するためには、同じオクテットに属するIPアドレスをどの組織に割り当てるか、明確にして管理しなければならないという点だ。だが現在では、CIDR（Classless Inter-Domain Routing：クラス・レスな経路集積型ルーティング）のために、IANAなど、各ネットワーク管理機関が地域別にまとめて割り当てる管理が行われているため、普通は混乱することはない。 もっとも、組織内でプライベート・アドレスを基にDNS環境（独自のドメイン・ツリー）を構築する場合にも、CIDRを意識したIPアドレスの振り分けをしていないと、ルーティングだけでなく、DNS環境においても影響が出る可能性がある。複数のサブドメインを運用するならば、個々のサブドメイン内で使用するIPアドレスは、同一サブネットに属するアドレスをまとめて使用した方がいい。注意しよう。 DNSの基本的な考え方については理解していただけたかと思う。次回は、現実のインターネットの中でのDNSの姿について、さまざまな観点から見てみることにしよう。 トラブルシューティングに便利な各種コマンド／ツール事典。各ツールの活用法をまとめたTipsも順次アップデート！ 社内のPCが突然、メールを受信できなくなり、Webも見られない環境になってしまった。そんなとき、どのように対処するべきか 名前しか知らない後輩君がやってきた。彼によると、コマンドはすでに古くツールがクールだという。ならば教えてもらおうではないか 5分で絶対に分かるSIP （2007/11/16）インターネットで電話をかけるためには、発信や着信、応答、切断といった制御が必要です。その手順を取り決めたシグナリングプロトコルの1つ、SIPを5分で理解しましょう 携帯メールポータビリティは開国を迫る黒船となるか （2007/10/31） 丹後から日本のケータイにもの申す。TANGOメールは携帯電話ネットワークのオープン化への第一歩となるか？ 「はてな」を作り出す人的ネットワークの仕組みとは （2007/8/24） 次々とWeb2.0的サービスをリリースするはてな。拡大する組織の中で行われているコミュニケーションのかたちとは？ ＠IT ネットワーク用語辞典 （2007/8/22）ネットワーク管理者のための用語集です。「LAN」や「IPアドレス」といった基本中の基本から、「HTTP」などのプロトコル、「ping」などのコマンドまで、幅広く解説します 技術者としての力量を数値で把握していますか？ITSSレベルを無料で判定、12月25日（火）まで ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン |
[ 202] DNSの仕組みの基本を理解しよう
[引用サイト] http://www.atmarkit.co.jp/fnetwork/rensai/dns01/dns01.html
