この付録では、XFN リファレンスにおける、DNS 文書 (TXT) レコードと X.500 属性の使用方法についての補足情報を述べます。
Solaris の環境は、DNS 内で広域ネーミングシステムをフェデレートさせるための XFN 規格に準拠しています。DNS でネーミングシステムをフェデレートさせるには、DNS TXT リソースレコードに情報を入力する必要があります。この情報は、従属ネーミングシステム用に XFN リファレンスを作成するために使用されます。この付録では、これらの DNS TXT レコードの書式について説明します。
DNS をフェデレートさせるのに必要な手順については、第 26 章「FNS およびグローバルネーミングシステム」を参照してください。
DNS 内のレコードを操作する一般的な方法の詳細は、『DNS and BIND』(Paul Albitz & Cricket Liu 著 浅羽登志也/上水流由香 監訳、アスキー出版局、1995年) を参照してください。
XFN リファレンスのリファレンスタイプは、XFNREF というタグで始まる TXT レコードから作成します。書式は以下の通りです。
TXT "XFNREF rformat reftype" |
TXT の後に続く文字列の中にスペースが存在する場合、そのスペースを削除するか、文字列全体を引用符 (" ") で囲む必要があります。XFNREF、rformat、reftype という 3 つのフィールドは、スペース (スペースとタブ) で区切ります。rformat は、リファレンスタイプの識別子の書式を指定します。種類は次のとおりです。
reftype は、リファレンスタイプの識別子の内容を指定します。
XFNREF レコードが存在しない場合、リファレンスタイプはデフォルト設定により FN_ID_STRING を持つ XFN_SERVICE 識別子になります。2 つ以上の XFNREF TXT レコードが存在する場合、どのレコードが処理されるかは不定です。以下の TXT レコードはデフォルト設定の XFNREF と同じ働きをします。
TXT "XFNREF STRING XFN_SERVICE" |
XFN リファレンスのアドレス情報は、XFN 文字列を接頭語にしたタグを持つ TXT レコードを使用して作成します。1 つのリファレンスに複数のアドレスを指定することもできます。同じタグを持つレコードはグループにまとめられ、グループごとにハンドラに渡されます。各ハンドラは渡された TXT レコードからアドレス (複数あるいは、ない場合もある) を作成し、リファレンスに付加します。XFNREF タグの場合は特別で、リファレンスタイプを作成するためにだけ使用されるため、アドレス作成の過程からは除外されます。
TXT レコードのアドレスを指定する構文は次のとおりです。
XFNaddress_type_tag address_specific_data |
XFN_address_type_tag と address_specific_data という 2 つのフィールドは、スペース (スペースとタブ) で区切ります。address_type_tag は、address_specific_data に使用するハンドラを指定します。
TXT レコードには 1 レコードにつき 2 K バイトという文字の制限があります。特定のアドレスのデータが長すぎて 1 つの TXT レコードに格納できない場合は、以下のように複数の TXT レコードを使用できます。
TXT "XFNaddress_type_tag address_specific_data1" TXT "XFNaddress_type_tag address_specific_data2" |
特定のタグのハンドラが呼び出され、両方のデータが渡されます。ハンドラはこれら 2 行を解釈する順番を決定します。
TXT レコードの順番はあまり重要ではありません。異なるタグを持つ行がある場合、特定のタグのハンドラが呼び出される前に、同じタグを持つ行はグループにまとめられます。以下の例では、tag1 のハンドラは 2 つの文書行で呼び出され、tag2 のハンドラは 3 つの文書行で呼出されます。
TXT "XFNtag1 address_specific_data1" TXT "XFNtag2 address_specific_data2" TXT "XFNtag1 address_specific_data3" TXT "XFNtag2 address_specific_data4" TXT "XFNtag2 address_specific_data5" |
XFN リファレンスに使用できる TXT レコードの例を以下に示します。
「例 1」
TXT "XFNREF STRING XFN_SERVICE" TXT "XFNNISPLUS doc.com. nismaster 129.144.40.23" |
「例 2」
TXT "XFNREF OID 1.3.22.1.6.1.3" TXT "XFNDCE (1 fd33328c4-2a4b-11ca-af85-09002b1c89bb...)" |
以下は、従属ネーミングシステムがバインドされた DNS テーブルの例です。
$ORIGIN test.doc.com
@ IN SOA foo root.eng.doc.com (
100 ;; Serial
3600 ;; Refresh
3600 ;; Retry
3600 ;; Expire
3600 ;; Minimum
)
NS nshost
TXT "XFNREF STRING XFN_SERVICE"
TXT "XFNNISPLUS doc.com. nismaster 129.144.40.23"
nshost IN A 129.144.40.21
|
この節では、XFN リファレンス用の X.500 属性の使用についての補足情報を述べます。XFN リファレンスを X.500 における属性として保存できるようにするためには、ディレクトリスキーマを、この付録で定義されているオブジェクトクラスと属性をサポートするように変更する必要があります。
X.500 を連合させるのに必要な手順については、第 26 章「FNS およびグローバルネーミングシステム」を参照してください。
X.500 のディレクトリスキーマの変更については、『 Managing the X.500 Client Toolkit 』を参照してください。
XFN リファレンスをサポートするために、XFN と XFN 補助の 2 つの新しいオブジェクトクラスが導入されています。XFN オブジェクトクラスは FNS に適切ではありません。これは、米国 Sun Microsystems, Inc. の X.500 ディレクトリ製品が、新しく導入された複合 ASN.1 構文をサポートしていないためです。その代わりに、FNS では XFN 補助オブジェクトクラスを使用します。
ASN.1 では、次のような 2 つの新しいオブジェクトクラスが定義されています。
xFN OBJECT-CLASS ::= {
SUBCLASS OF { top }
KIND auxiliary
MAY CONTAIN { objectReferenceId |
objectReference |
nNSReferenceId |
nNSReference }
ID id-oc-xFN
}
id-oc-xFN OBJECT IDENTIFIER ::= {
iso(1) member-body(2) ansi(840) sun(113536)
ds-oc-xFN(24)
}
xFNSupplement OBJECT-CLASS ::= {
SUBCLASS OF { top }
KIND auxiliary
MAY CONTAIN { objectReferenceString |
nNSReferenceString }
ID id-oc-xFNSupplement
}
id-oc-xFNSupplement OBJECT IDENTIFIER ::= {
iso(1) member-body(2) ansi(840) sun(113536)
ds-oc-xFNSupplement(25)
}
|
XFN 補助オブジェクトクラスは、補助オブジェクトクラスとして定義されているため、X.500 のオブジェクトクラスすべてに引き継がれる可能性があります。XFN 補助オブジェクトクラスは、以下の 2 つの任意属性によって定義されます。
ASN.1 では、この 2 つの属性を以下のように定義しています。
objectReferenceString ATTRIBUTE ::= {
WITH SYNTAX OCTET STRING
EQUALITY MATCHING RULE octetStringMatch
SINGLE VALUE TRUE
ID { id-at-objectReferenceString }
}
id-at-objectReferenceString OBJECT IDENTIFIER ::= {
iso(1) member-body(2) ansi(840) sun(113536)
ds-at-objectReferenceString(30)
}
nNSReferenceString ATTRIBUTE ::= {
WITH SYNTAX OCTET STRING
EQUALITY MATCHING RULE octetStringMatch
SINGLE VALUE TRUE
ID { id-at-nNSReferenceString }
}
id-at-nNSReferenceString OBJECT IDENTIFIER ::= {
iso(1) member-body(2) ansi(840) sun(113536)
ds-at-nNSReferenceString(31)
}
|
objectReferenceString と nNSReferenceString は、共に XFN リファレンスを文字列形式で保存します。それぞれのオクテット列構文は、さらに以下の BNF 定義に準拠するように制約を加えられます。
<ref> ::= <id> '$' <ref-addr-set>
<ref-addr-set> ::= <ref-addr> | <ref-addr> '$' <ref-addr-set>
<ref-addr> ::= <id> '$' <addr-set>
<addr> ::= <hex-string>
<id> ::= 'id' '$' <string> |
'uuid' '$' <uuid-string> |
'oid' '$' <oid-string>
<string> ::= <char> | <char> <string>
<char> ::= <PCS> | '¥' <PCS>
<PCS> ::= // Portable Character Set:
// !"#$%&'()*+,-./0123456789:;<=>?
// @ABCDEFGHIJKLMNOPQRSTUVWXYZ[¥]^_
// `abcdefghijklmnopqrstuvwxyz{|}‾
<uuid-string> ::= <uuid-char> | <uuid-char> <uuid-string>
<uuid-char> ::= <hex-digit> | '-'
<oid-string> ::= <oid-char> | <oid-char> <oid-string>
<oid-char> ::= <digit> | '.'
<hex-string> ::= <hex-octet> | <hex-octet> <hex-string>
<hex-octet> ::= <hex-digit> <hex-digit>
<hex-digit> ::= <digit> |
'a' | 'b' | 'c' | 'd' | 'e' | 'f' |
'A' | 'B' | 'C' | 'D' | 'E' | 'F'
<digit> ::= '0' | '1' | '2' | '3' | '4' | '5' |
'6' | '7' | '8' | '9'
|
以下は、文字列形式の XFN リファレンスの例です。
id$onc_fn_enterprise$id$onc_fn_nisplus_root$0000000f77697a2e636fd2e2062696762696700 |
この例では、onc_fn_enterprise というタイプの XFN リファレンスを使用しています。この中には、onc_fn_nisplus_root というアドレスタイプと 1 つのアドレス値があります。アドレス値は XDR によって符号化された文字列で、ドメイン名、doc.com の後にホスト名 cygnus が続く形で構成されています。
XFN リファレンスは、fnattr という FNS コマンドを使用して X.500 のエントリに加えることができます。この例では、次のように入力すると、c=us/o=doc という新しいエントリが作成され、オブジェクトクラスの属性と最上位、組織、XFN 補助の値が加えられます。
# fnattr -a .../c=us/o=doc object-class top organization xfn-supplement |
fnbind という FNS コマンドは、NIS+ リファレンスを命名されたエントリにバインドし、X.500 を NIS+ 名前空間のルートにリンクします。fnbind の名前因数内の文字の後にスラッシュ (/) が使用されていることに注意してください。
# fnbind -r .../c=us/o=doc/ onc_fn_enterprise onc_fn_nisplus_root "doc.com. cygnus" |