グローバルネームサービスには、固有の適用範囲があります。ここでは、グローバルネームサービスを使用するオブジェクトをネーミングするためのポリシーについて説明します。
ネーミングに関しては、エンタープライズは、グローバル名前空間にあるエンタープライズのルートをバインドして、フェデレートされたグローバル名前空間にリンクします。これにより、エンタープライズ外部のアプリケーションおよびユーザーがそのエンタープライズ内部のオブジェクトをネーミングできます。たとえば、エンタープライズ内部のユーザーは、他のエンタープライズにいる同僚にファイルのグローバル名を渡すことができます。
DNS および X.500 のコンテキストは、エンタープライズをネーミングするためのグローバルレベルのネームサービスを提供します。FNS では、DNS と X.500 コンテキストの両方がサポートされます。FNS がない場合、DNS および X.500 では、限定された部分のエンタープライズ名前空間だけに外部からアクセスできます。FNS では、カレンダマネージャなどのサービスを含むエンタープライズ名前空間全体に外部からアクセスできます。
原子名「...」(3 つのドット) は、各 FNS クライアントの初期コンテキストに表示されます。原子名「...」は、グローバル名が解決されるコンテキストにバインドされます。
表 21-5 グローバルネーミングに対する初期コンテキストバインド
原子名 |
バインド |
---|---|
. .. |
DNS または X.500 の名前を解決するためのグローバルコンテキスト |
/ ... |
3 つのドットの同義語 |
グローバル名は、完全指定のインターネットドメイン名か、または X.500 の識別名になります。
インターネットドメイン名は、インターネット RFC 1035 で指定された構文に表示される。たとえば、.../doc.com (「DNS のフェデレーティング」を参照) など
X.500 名は、X/Open DCE ディレクトリで決定された構文に表示される。たとえば、.../c=us/o=doc など (「X.500/LDAP のフェデレーティング」を参照)
名前「...」および「/...」は、初期コンテキストで解決されるときには等価になります。たとえば、名前 /.../c=us/o=doc および .../c=us/o=doc は、初期コンテキストで同じオブジェクトとして解決されます。
完全指定の DNS 名は、必ずグローバルコンテキストで使用できます。DNS 名がグローバル名前空間で見つかると、リゾルバライブラリを使用して解決されます。リゾルバライブラリは、DNS 名前解決メカニズムです。一般的 DNS 名は、インターネットのホストアドレスまたは DNS ドメインレコードで解決されます。グローバルコンテキストで DNS 名が検出されると、名前は DNS リゾルバに引き渡されて解決されます。結果は、XFN リファレンス構造に変換され、要求者に返されます。
DNS ドメインの内容は、表示できます。しかし、表示操作は、インターネットでの連結性とセキュリティなどの実用上の理由によって限定されることもあります。たとえば、DNS ドメインのグローバルルート表示は、一般的にルート DNS サーバーではサポートされません。しかし、ルートの下にあるたいていのエンティティは、表示操作をサポートします。
DNS ホストおよびドメインは、DNS リソース名と関連付けられたネームサービス (NS) のリソースレコードの有無によって確認されます。
「DNS ドメイン名」
NS レコードがリソース名に存在する場合は、その名前はドメイン名であると考えられ、返されたリファレンスのタイプは inet_domain となる
「DNS ホスト名」
NS レコードがリソース名に存在しない場合は、その名前はホスト名であると考えられ、返されたリファレンスのタイプは inet_host となる
DNS は、端末以外のネーミングシステムのように機能し、他のネーミングシステムをフェデレートするために使用されます。
たとえば、エンタープライズネーミングシステムは、FNS 名 .../doc.com/ がそのエンタープライズの FNS 名前空間のルートを参照するような DNS にある doc.com にバインドできます。
エンタープライズのネーミングシステムは、適切なテキスト (TXT) レコードをそのドメインの DNS マップに追加して、DNS ドメインにバインドされます。そのドメインに対する FNS 名には後に続くスラッシュ (/) が含まれ、TXT リソースレコードは、エンタープライズのネーミングシステムへのリファレンスを構成するために使用されます。
DNS に関する一般的な情報については、in.named(1M) のマニュアルページか、または『Solaris ネーミングの設定と構成』の DNS についての章を参照してください。
X.500 は、グローバルのディレクトリサービスです。ここでは、情報が格納され、情報を表示して検索する機能と同様に、名前で情報を検索する機能が提供されます。
X.500 の情報は、ディレクトリ情報ベース (DIB) に格納されます。DIB にあるエントリは、ツリー構造で配列されます。各エントリは名前付きオブジェクトで、定義された属性のセットを含んでいます。各属性には、定義済みの属性タイプと 1 つまたは複数の値があります。
エントリは、ルートから名前付きエントリまでのパスでツリー内の各エントリから選択された属性の連結である「識別名」によって明確に識別されます。たとえば、図 21-6 に示す DIB を使用すると、c=us/o=doc は、合衆国にある doc 組織の識別名となります。X.500 ディレクトリのユーザーは、DIB にあるエントリと属性を問い合わせたり、変更したりすることができます。
FNS は、名前空間をグローバル X.500 名前空間の下にシームレスに接続して表示するために必要なサポートを提供し、X.500 をフェデレートします。
たとえば、FNS は、X.500 の下の doc 組織にエンタープライズネーミングシステムをリンクします。初期コンテキストから始まって、doc 組織の sales 組織単位を識別する FNS 名は次のようになります
.../c=us/o=doc/orgunit/sales
エンタープライズ内の名前は、単純にグローバルの X.500 名上に連結されます。(FNS 名が初期コンテキストで名前「...」を使用して、グローバル名が後に続くことを示すことに注意してください。)
FNS 名の名前解決は、次のように行われます。X.500 名がグローバル名前空間で見つかると、X.500 名前解決メカニズムを使用して解決されます。次の 3 つの結果が考えられます。
フルネームが X.500 エントリに解決される。これは、エントリが X.500 に格納されていることを示す。要求された FNS 操作がそのエントリで実行される
フルネームの接頭辞は、X.500 エントリに解決される。これは、名前の残りの部分が従属するネーミングシステムに所属することを示す
従属するネーミングシステムへの次のネーミングシステムのポインタ (NNSP) が調べられ、XFN リファレンスが返されます。この後、名前解決は従属するネーミングシステムで続けられます。
エラーが報告される
X.500 エントリは、FNS 操作を使用して調べたり、変更したりできます (アクセス制御に従う)。しかし、現在は FNS を使用して X.500 名前空間のルートの下にある従属するエントリを表示できません。