DNS (Domain Name System) の構成ファイルは,省略時の設定では
/etc/namedb/named.boot
という名前で作成され,DNS データ・ファイルの名前を指定します。
これらのデータ・ファイルは,この章で説明するフォーマットのエントリで構成されます。
データ・ファイル・エントリのことをリソース・レコード (RR) とも呼びます。
G.1 DNS リソース・レコードのフォーマット
DNS リソース・レコードの一般的なフォーマットは次のとおりです。
name ttl addr-class entry-type entry-specific-data
フィールド | 説明 |
name | このフィールドには,たとえば
データ・ファイル・エントリによっては,name フィールドが空白のままの場合があります。 その場合,ドメイン名は,前のエントリと同じであるとみなされます。 独立したピリオド (.) は,現在のドメインを示します。 独立したアット・マーク ( 2 つの独立したピリオド ( |
ttl | このフィールドは time-to-live フィールドで,データがデータベースに格納される時間を秒数で表します。 このフィールドが空白の場合,SOA (start of authority) エントリに指定されている ttl 値が使用されます。 この値が指定されていない場合には,$ttl エントリの値が使用されます。 格納時間の最大値は 99999999 秒,すなわち 3 年間です。 |
addr-class | このフィールドはアドレス・クラスです。 クラスには,IN (インターネット・アドレス),TXT (ネーミング・サービス・データ),ANY (他のすべてのタイプのネットワーク・アドレス) の 3 つがあります。 特定のゾーンにある所定の entry-type のデータ・ファイル・エントリのアドレス・クラスは,すべて同じでなければなりません。 したがって,ゾーンの最初のエントリのみ addr-class フィールドを指定する必要があります。 |
entry-type | このフィールドは,リソースのレコード・タイプを示します。 SOA (start of authority),A (address) などがあります。 |
entry-specific-data | entry-type フィールドより後ろのフィールドは,データ・ファイル・エントリ (リソース・レコード) のタイプによって異なります。 |
DNS サーバへのロード時には,名前とデータ・フィールドの大文字小文字の区別はそのままです。 DNS による比較と検索では,大文字と小文字は区別されません。
次の文字は,DNS データ・ファイル・エントリの中で特別な意味を持ちます。
文字 | 意味 |
\x | バックスラッシュ (\) は,その後に続く数字でない文字 (x) の本来持つ特別な意味を適用しないよう,エスケープ処理します。 たとえば,ピリオド (.) の前にバックスラッシュを付けて,ラベルの中でピリオド文字を使用することができます。 |
\nnn | nnn で表される 10 進数の前にバックスラッシュを付けると,対応するオクテットを意味します。 これによって生成されるオクテットはテキストとみなされ,特別な意味があるかどうかのチェックは行われません。 |
() | カッコは,数行にわたるデータをグループ化します。 カッコ内では,行の終わりは認識されません。 |
; | セミコロンはコメントの始まりを意味し,その行の残りの部分は無視されます。 |
* | アスタリスクはワイルドカードです。 |
DNS データ・ファイル・エントリがピリオド (.) で終わっていない場合,DNS データ・ファイル・エントリに記述されている名前に現在のドメイン名を追加します。 これは,現在のドメイン名をシステム名のようなデータに追加する場合には便利ですが,問題の発生の原因になる可能性もあります。 したがって,その名前がデータ・ファイルを作成しているドメイン中の名前でない場合は,名前の最後にピリオドを打ちます。
データ・ファイル (リソース・レコード) は次のタイプのエントリを持つことができます。
次の項では,それぞれのデータ・ファイル・エントリとそのフォーマットについて説明します。
G.2.1 インクルード・エントリ
インクルード・エントリは,C プログラミング言語のヘッダ・ファイルと同じように機能します。
この機能は,異なるタイプのデータを複数のファイルに分けるのに便利です。
インクルード・エントリは,最初のカラムが
$include
で始まり,インクルードするファイルの名前がその後に続きます。
次に例を示します。
$include /etc/namedb/mailboxes
このエントリは,DNS にデータ・ファイル
/etc/namedb/mailboxes
をロードするよう要求します。
インクルード・エントリは,データ・ファイルをローカル・ゾーンにロードし,データ・ファイル・オーガナイザとして動作します。
たとえば,$include
を使用してホスト情報からメールを区別することができます。
G.2.2 起点エントリ
起点エントリは,データ・ファイルの起点を変更します。
この機能は,1 つのデータ・ファイルに複数のドメインを入れる場合に特に便利です。
次の例に示すように,起点エントリは最初のカラムが
$origin
で始まり,続いてドメインの起点が記述されます。
$origin state.dec.com.
このエントリは,データ・ファイルにドメイン
state.dec.com
をインクルードします。
その結果,サーバがそのゾーンについて権限を持っていれば,DNS は,ローカル・ドメインに加えて
state.dec.com
ドメインについての情報を提供することができます。
$origin
および
$include
のエントリは,同時に使用することができます。
これらの機能を利用すると,入力の手間を省き,ファイルを整理された状態に保つことができます。
たとえば,hosts.rev
ファイルに次のエントリが含まれているとします。
$origin ll.128.in-addr.arpa. $include cities.dec.com.rev
arpa
の後のピリオドは,それが完全なドメイン名であることを示します。
ここでは,cities.dec.com.rev
ファイルは次のようなエントリで構成されていると仮定します。
33.22 IN PTR chicago.cities.dec.com.
この場合,ホスト chicago の完全なリバース・ネームが次のように変換されます。
33.22.11.128. in-addr.arpa. IN PTR chicago.cities.dec.com.
格納時間エントリは,他のリソース・レコードの ttl フィールドと同様に,データがキャッシュに格納される時間の長さを指定します。
ただし,格納時間を
$ttl
エントリに指定した場合でも,リソース・レコードまたは対応する SOA レコードに格納時間が指定されていない場合だけ有効になります。
このエントリは,省略可能です。
$ttl
エントリは,第 1 カラムが
$ttl
,第 2 カラムが値,第 3 カラムがコメント (省略可能) です。
たとえば,次のエントリは,ttl が指定されていないリソース・レコードの格納時間を 21600 秒 (6 時間) とします。
$ttl 21600 default time to live
この方法を使用する場合,設定できる格納時間は 0 〜 2147483647 秒です。 格納時間は,次のフォーマットで指定することも可能です。 この場合,必ずしもすべてのフィールドに値を指定する必要はありません。
weeksWdaysDhoursHminutesMsecondsS
たとえば,このフォーマットでの最大値 (3550 週,5 日,3 時間,14 分,7 秒) は,次のように指定します。
$ttl 3550W5D3H14M7S
アドレス (A) ・データ・ファイル・エントリは,特定のシステムの IPv4 アドレスをリストします。 A エントリのフォーマットは次のとおりです。
name ttl addr-class entry-type address
A エントリの各フィールドには,G.1 節で説明している値が入りますが,address フィールドだけは例外です。 このフィールドには,それぞれのシステムの IPv4 アドレスを指定します。 1 つのシステムに着目すると,各アドレスに対する A エントリは 1 つだけでなければなりません。
2 つの A エントリの例を次にを示します。
;name ttl addr-class entry-type address miami.cities.dec.com. IN A 128.11.22.44 IN A 128.11.22.33
この例では,ホスト miami.cities.dec.com には IP アドレスが 2 つあり,どちらも IPv4 です (IPv4 アドレスと IPv6 アドレスを持つホストの例は,G.2.5 項 を参照してください)。
最初のエントリでは,ttl
フィールドが空白なので,SOA エントリまたは $ttl エントリで指定されている省略時の ttl が使用されます。
2 番目のエントリでは,1 番目と 2 番目のフィールドが空白なので,前のエントリで指定された省略時の名前と,同じく省略時の ttl が使用されます。
G.2.5 IPv6 アドレス・エントリ
IPv6 アドレス (AAAA) データ・ファイル・エントリは,特定の IPv6 システムのアドレスをリストします。 AAAA エントリの形式は次のとおりです。
name ttl addr-class entry-type address
AAAA エントリのフィールドには G.1 節 で説明している値が入りますが,address フィールドだけは例外です。 このフィールドには,それぞれのシステムの IPv6 アドレスを指定します。 1 つのシステムに着目すると,各アドレスに対する AAAA エントリは 1 つだけでなければなりません。
AAAA エントリの例を次にを示します。
;name ttl addr-class entry-type address boston.cities.dec.com. IN A 128.11.22.42 IN AAAA 1070:0:0:0:0:800:200C:417B
この例では,ホスト boston.cities.dec.com には IP アドレスが 2 つあり,片方が IPv4 アドレスでもう片方が IPv6 アドレスです。 一部の IPv6 構成では AAAA エントリと A エントリを組み合わせるのが一般的です。 これにより,IPv4 ネットワークとの互換性が確保できるからです。
IPv6 の詳細については 『ネットワーク管理ガイド:接続編』 を参照してください。
G.2.6 正式名エントリ
正式名 (CNAME) エントリは,正式名に対する別名を指定します。 たとえば,正式名 (完全 DNS 名または完全修飾名とも呼ぶ) が miami.cities.dec.com の場合,別名は miami または mi などが考えられます。
別名はユニークでなければならず,他のすべてのエントリは,別名ではなく正式名に関連付けられていなければなりません。 別名を定義してそれを他のエントリの中で使用してはなりません。 CNAME エントリのフォーマットは次のとおりです。
aliases ttl addr-class entry-type can-name
CNAME エントリの各フィールドには,G.1 節で説明する値が入りますが,次のフィールドは例外です。
フィールド | 説明 |
alias | このフィールドには,ホストの正式名のニックネーム (別名) を指定します。 |
can-name | このフィールドにはホストの正式名を指定します。 正式名が現在のドメインの一部である場合,たとえば miami のようにホスト名だけを指定します。 他のドメインのホストの正式名を指定する場合は,DNS の完全修飾名とそれに続けてピリオド (.) を記述します。 たとえば,ohio.state.dec.com. のように指定します。 |
次の例は,2 つの CNAME エントリを示しています。 最初のエントリは現在のドメイン cities.dec.com の CNAME を指定し,2 番目のエントリは他のドメインにある CNAME を指定しています。
;aliases ttl addr-class entry-type can-name to IN CNAME toledo oh IN CNAME ohio.state.dec.com.
ホスト情報 (HINFO) データ・ファイル・エントリは,ホスト固有の情報を指定するためのエントリです。 このエントリには,特定のホスト・システムで稼働しているハードウェアとオペレーティング・システムをリストします。 ハードウェア名とオペレーティング・システム情報は,1 つのスペースで区切ります。 したがって,ホストまたはオペレーティング・システム名の一部としてスペースを使用する必要がある場合,名前を引用符で囲まなければなりません。 加えて,ドメイン上のそれぞれのホストに対し,HINFO は 1 つだけしか設定できません。 HINFO エントリのフォーマットは次のとおりです。
host ttl addr-class entry-type hardware opsys
HINFO エントリの各フィールドには,G.1 節で説明する値が入りますが,次のフィールドは例外です。
フィールド | 説明 |
host | このフィールドにはホスト名を指定します。 ホストが現在のドメインに存在する場合は,たとえば chicago のように,ホスト名だけを指定します。 ホストが別のドメインに存在する場合は,たとえば utah.state.dec.com. のように,DNS の完全修飾名を指定します。 この場合,ホスト名の最後にはピリオド (.) を必ずつけます。 ピリオドによって,DNS の完全修飾名であることを示します。 |
hardware | このフィールドには,たとえば AlphaServer 8400 のように CPU のタイプを指定します。 |
opsys | このフィールドには,指定したホストで実行されているオペレーティング・システムのタイプを指定します。 Tru64 UNIX オペレーティング・システムの場合には,Tru64 UNIX が推奨されます。 |
HINFO エントリの例を次に示します。
;name ttl addr-class entry-type hardware opsys ohio.state.dec.com. IN HINFO "AlphaServer 8400" "Tru64 UNIX"
この例では,ttl を指定する 2 番目のフィールドが空白なので,SOA エントリまたは $ttl エントリで指定されている省略時の ttl が使用されます。
G.2.8 メールボックス・エントリ
メールボックス (MB) ・エントリは,ユーザがメールを受け取るシステムをリストします。 MB エントリのフォーマットは次のとおりです。
login ttl addr-class entry-type system
MB エントリの各フィールドには,G.1 節で説明する値が入りますが,次のフィールドは例外です。
フィールド | 説明 |
login | このフィールドには,ユーザのログイン名を指定します。 ログイン名は,ドメインでユニークでなければなりません。 |
system | このフィールドには,ユーザがメールを受信するネーム・システムを指定します。 |
MB エントリの例を次に示します。
;login ttl addr-class entry-type system fred IN MB potsdam.cities.dec.com.
この例では,2 番目のフィールドが空白なので,SOA エントリまたは $ttl エントリで指定されている省略時の ttl が使用されます。
このエントリの設定では,ユーザ fred は,ドメイン cities.dec.com にある potsdam という名前のホストでメールを受け取ります。
G.2.9 メール・グループ・エントリ
メール・グループ (MG) エントリは,メール・グループのメンバを指定します。 MG エントリは,通常,MINFO エントリとともに使用されます。 メール・グループ・エントリのフォーマットは次のとおりです。
group ttl addr-class entry-type member
MG エントリの各フィールドには,G.1 節で説明する値が入りますが,次のフィールドは例外です。
フィールド | 説明 |
group | このフィールドには,たとえば users や marketing のようなメール・グループ名を指定します。 |
member | このフィールドには,メール・グループに含めるログイン名とユーザのドメインを指定します。 |
MINFO エントリと MG エントリの例を次に示します。
;group ttl addr-class entry-type requests member fun IN MINFO BIND-REQUEST fred@miami.cities.dec.com. IN MG john@miami.cities.dec.com. MG amy@miami.cities.dec.com.
この例では,3 つのエントリすべてに関して,2 番目のフィールドが空白なので,SOA エントリまたは $ttl エントリで指定されている省略時の ttl が使用されます。
加えて,Fred,John,および Amy は,メール・グループ fun 宛てに送信されたメールをすべて受け取ります。
G.2.10 メールボックス情報エントリ
メールボックス情報 (MINFO) エントリは,メーリング・リストのためのメール・グループを作成します。 MINFO エントリは,通常,メール・グループ (MG) エントリに関連付けられていますが,メールボックス (MB) エントリとともに使用することもできます。 MINFO エントリの例を次に示します。
mailbox ttl addr-class entry-type requests maintainer
MINFO エントリの各フィールドには,G.1 節で説明する値が入りますが,次のフィールドは例外です。
フィールド | 説明 |
mailbox | このフィールドにはメールボックスの名前を指定します。
この値は通常,BIND
です。 |
requests | このフィールドには,DNS またはメールに関連するメールの宛先の名前を指定します。 たとえば別名をセットアップするよう要求するメール・メッセージを送信する場合などに使用します。 |
maintainer | このフィールドには,メールのエラー・メッセージを受け取るユーザのログイン名を指定します。 このフィールドは,メンバの名前で生じたエラーを送信者以外の人にレポートする必要がある場合に特に便利です。 |
MINFO エントリの例を次に示します。
mailbox ttl addr-class entry-type requests maintainer BIND IN MINFO BIND-REQUEST fred@miami.cities.dec.com.
この例では,2 番目のフィールドが空白なので,SOA エントリまたは $ttl エントリで指定されている省略時の ttl が使用されます。
G.2.11 メール・リネーム・エントリ
メール・リネーム (MR)・エントリは,特定のユーザの別名をリストします。 MR エントリのフォーマットは次のとおりです。
alias ttl addr-class entry-type login
MR エントリの各フィールドには,G.1 節で説明する値が入りますが,次のフィールドは例外です。
フィールド | 説明 |
alias | このフィールドには,指定したユーザのニックネームをリストします。 別名は,ドメインでユニークでなければなりません。 |
login | このフィールドには,別名が設定されているユーザのログイン名を指定します。 指定されたログイン名に関しては,対応する MB エントリも必要になります。 ログイン名は,ドメインでユニークでなければなりません。 |
MR エントリの例を次に示します。
;alias ttl addr-class entry-type login lady IN MR diana princess IN MR diana
この例は,ログイン名が diana のユーザに lady と princess という別名をセットアップする方法を示しています。
2 番目のフィールドが空白なので,SOA エントリまたは $ttl エントリで指定されている省略時の ttl が使用されます。
G.2.12 メール・エクスチェンジャ・エントリ
メール・エクスチェンジャ (MX)・エントリは,ローカル・ネットワークに直接接続されていないシステムへのメールの配信方法を知っている,ローカル・ドメイン中のシステム (ゲートウェイと呼ぶ) を指定します。 MX エントリは,ローカル・ネットワークの外側から,ネットワーク内のいずれかのホストのユーザにメールを送るシステムにとって便利です。
また MX エントリを使用して
/etc/hosts
ファイルにあるホストの一部をリストすることにより,DNS サービスを使用している他のシステムから見えないようにすることもできます。
MX エントリの各フォーマットは次のとおりです。
system ttl addr-class entry-type pref-value gateway
MX エントリの各フィールドには,G.1 節で説明する値が入りますが,次のフィールドは例外です。
フィールド | 説明 |
system | このフィールドには,メールの宛先システムの名前を指定します。 |
pref-value | このフィールドには,特定のシステムへのメール配信方法が複数ある場合にメーラが従うべき順序を指定します。 |
gateway | このフィールドには,ゲートウェイ・システム,すなわち,他のネットワーク上のシステムにメールを配信できるシステムの名前を指定します。 |
次に 2 つの MX エントリの例を示します。
;system ttl addr-class entry-type pref-value gateway tampa.cities.dec.com IN MX 0 seismo.cs.au. *.folks.dec.com IN MX 0 relay.cs.net.
この例では,ドメイン folks.dec.com に宛てられたメールはすべて,ホスト名にかかわらず,relay.cs.net ホストによるルーティングによって送信されます。
加えて,両方のエントリの ttl フィールドが空白なので,SOA エントリまたは $ttl エントリで指定されている省略時の ttl が使用されます。
2 番目のエントリはアスタリスク,すなわちワイルドカードを使用しています。
G.2.13 ネーム・サーバ・エントリ
ネーム・サーバ (NS) ・エントリは,当該システムが,指定されたドメインのネーム・サーバであることを指定します。 NS エントリのフォーマットは次のとおりです。
name ttl addr-class entry-type server
NS エントリの各フィールドには,G.1 節で説明する値が入りますが,server フィールドは例外です。 このフィールドは,最初のフィールドで指定されたドメインの 1 次マスタ・サーバの名前を指定します。
NS エントリの例を次に示します。
;name ttl addr-class entry-type server IN NS utah.states.dec.com.
ドメイン名ポインタ (PTR)・エントリを指定すると,ドメインの他の位置をポイントする特別な名前を使用することができます。
PTR 名はゾーン内で一意でなければなりません。
これらのエントリは,/etc/namedb/hosts.rev
ファイルの 1 次サーバの上に置かれます。
PTR エントリのフォーマットを次に示します。
rev-addr ttl addr-class entry-type hostname
PTR エントリの各フィールドには,G.1 節で説明する値が入りますが,次のフィールドは例外です。
フィールド | 説明 |
rev-addr | このフィールドには,ホストのリバース IP アドレスを指定します。 たとえば,ホストのアドレスが 128.11.22.33 の場合,リバース・アドレスは 33.22.11.128.in-addr.arpa になります。 このフィールドには IPv6 アドレスも指定できます。
IPv6 アドレスは,4 ビットのニブルを逆順にピリオドで区切ったものにサフィックス |
hostname | このフィールドには,DNS の完全修飾名を指定します。 たとえば miami.cities.dec.com のようになります。 ホストが現在のドメインでない場合は,必ず最後にピリオド (.) を付けます。 |
次に,2 つの IPv4 PTR エントリの例を示します。
;rev-addr ttl addr-class entry-type hostname 33.22 IN PTR chicago 66.55.44.121.in-addr.arpa. IN PTR mail.peace.org.
この例では,最初のエントリは,現在のドメインで IP ホスト・アドレスが
22.33
であるホストに対するエントリです。
指定されているリバース・アドレス (33.22
) は,$origin
エントリが存在する場合には意味があります。
$origin
エントリの詳細については,G.2.2 項を参照してください。
$origin
エントリが存在しない場合,IP アドレス全体をリバースで指定する必要があります。
2 番目のエントリは,別のドメイン (mail.peace.org.) のホストに対するエントリです。
ただし,この指定は,自分のサーバのキャッシュに,そのサーバが権限を持たないデータを入れることになるので,原則的に使用しないでください。
PTR エントリおよび他のリソース・レコードは,自分のドメインにあるホストのみが対象です。
PTR エントリは,ホスト
mail.peace.org
のリバース・ポインタをセットアップします。
IPv6 PTR エントリの例を次に示します。
;rev-addr ttl addr-class entry-type hostname $ORIGIN 0.0.7.a.f.e.f.f.f.8.f.0.0.2.0.0.6.8.1.1.0.2.0.0.5.0.8.e.f.f.3.ip6.int. d 3600 IN PTR equinox.ipv6.campus.edu.
この例では,管理者は
$origin
エントリを使用して,整ったリソース・コードを作成しています。
$origin
エントリに IPv6 アドレスのほとんどを指定することで,PTR エントリが次の行にまたがらないようにすることができます。
このエントリに対するフォワード IPv6 アドレスは,3ffe:8050:201:1860:0200:f8ff:fefa:700d です。
IPv6 の詳細は,『ネットワーク管理ガイド:接続編』 を参照してください。
G.2.15 SOA エントリ
SOA (start of authority) エントリは,ゾーンの始まりを指定します。 SOA は 1 つのゾーンに複数指定することはできません。 SOA エントリのフォーマットを次に示します。
name ttl addr-class entry-type origin person serial# refresh retry expire min
SOA エントリの各フィールドには,G.1 節で説明する値が入りますが,次のフィールドは例外です。
フィールド | 説明 |
origin | このフィールドには,データ・ファイルが存在するホストの名前を指定します。 通常はマスタ・サーバを指定します。 |
person | このフィールドには,ローカル・ドメインで実行されている DNS の,責任者のログイン名とメール・アドレスを定義します。 |
serial# | このフィールドには,データ・ファイルのバージョン番号を指定します。 そのゾーンのマスタ・ファイルの編集者は,ファイルのデータに変更を加えるたびに,このフィールドの値をインクリメントしなければなりません。 シリアル番号を変更すると,マスタ・サーバから取得すべき新しいデータの存在が,2 次サーバに通知されます。 最大数は小数点以上が 232-1 です。 シリアル番号フィールドにより,DNS は,ゾーンにある 2 つのデータ・ファイルのどちらが新しいか判断できます。 通常,シリアル番号フィールドは 1 で始まり,オリジナルのデータ・ファイルが修正されるたびに 1 ずつインクリメントされます。 整数を使うのが適切です。 |
refresh | このフィールドには,2 次 DNS サーバがそのデータ・ファイルを更新する必要があるかどうかをマスタ・サーバに確認する頻度を秒数で指定します。 データ・ファイルが最新でない場合は (シリアル番号フィールドの不一致によって示される),マスタ・サーバのファイルの内容を使用して更新を行います。 最小の更新間隔は 30 秒です。 refresh フィールドが空白の場合,データ・ファイルは動的には更新されません。 |
retry | このフィールドには,更新中に障害が生じた場合,その後,2 次 DNS サーバがそのデータ・ファイルの更新を試みる頻度を秒数で指定します。 DNS サーバがファイルを更新しようとして失敗した場合,retry フィールドに指定されている秒数ごとに更新を実行します。 |
expire | このフィールドには,データ・ファイルが更新されなくてデータが期限切れになる前,あるいは,キャッシュの更新が必要でないか DNS サーバがチェックするまでに,キャッシュ内のデータ・ファイルを 2 次 DNS サーバが使用できる上限を秒数で指定します。 |
min | このフィールドには,ttl エントリが空白の場合に,データ・エントリが存在可能な省略時の有効時間を秒数で指定します。 |
SOA エントリの例を次に示します。 最初の行は,フィールドを示すコメントです。
;name ttl addr-class entry-type origin person @ IN SOA utah.states.dec.com. hes.utah.states.dec.com. ( 1 ; serial 3600 ; refresh every hr. 300 ; retry every 5 min. 3600000 ; expire in 1000 hrs. 86400 ) ; min. life is 24 hrs.
この例で,カッコは,これが 1 つのエントリであることを DNS に示しています。 ttl フィールドは空白で,min フィールドで指定されている省略時の生存時間 (86400 秒) が使用されます。
見やすいように,セミコロンを使用してコメントを入れることもできます。
例では,serial フィールドが 1 で,refresh フィールドは 3600 秒 (1 時間に 1 回),retry フィールドは 300 秒 (5 分に 1 回),expire フィールドは 3,600,000 秒 (1000 時間),min フィールドは 86400 秒 (24 時間) であることを示しています。
G.2.16 サービス位置エントリ
サービス位置 (SRV) エントリは,特定のターゲット・ドメインでサポートされるサービスを記述します。 これは,旧バージョンとの互換性のために残されている WKS (Well-known Services) エントリに代わるものです。 SRV エントリの形式は次のとおりです。
_service._protocol.name ttl addr-class entry-type priority weight target
SRV エントリのフィールドには G.1 節 で説明している値を記述しますが,次のフィールドは例外です。
フィールド | 説明 |
service | このフィールドは大文字と小文字を区別しません。
対象とするサービスのシンボリック名を指定します。
サービス名は,/etc/services
ファイルから選択することも,新しく一意の名前をローカルに定義することもできます。
サービス名の前には
_ldap
のように下線文字 (_) を付けて,他の DNS ラベルと衝突しないようにする必要があります。 |
protocol | このフィールドは大文字と小文字を区別しません。
使用するプロトコルのシンボリック名を指定します。
プロトコル名の前には
_TCP
や
_UDP
のように下線文字 (_) を付けて,他の DNS ラベルと衝突しないようにする必要があります。 |
name | このフィールドは SRV レコードが参照するドメインを指定します。 他のリソース・レコードと同じく,同じドメインのレコードのすぐ下に SRV レコードが挿入される場合,name フィールドは空白のままにしておくことができます。 |
priority | このフィールドはターゲット・システムまたはサーバの優先順位を 0 〜 65535 の数値で指定します。 指定したサービスのクライアントは,priority の値が最も小さいシステムに接続しようとします。 優先順位が同じシステムについては,weight フィールドで定義した順に試行されます。 |
weight | このフィールドは,priority の値が同じエントリの相対的な重みを 0 〜 65535 の数値で指定します。 重みの値が大きいほど選択されやすくなります。 |
port | このフィールドは,ターゲット・サーバ上のサービスのポートを 0 〜 65535 の数値で指定します。
ポート番号は,/etc/services
ファイルから選択することも,新しく一意の番号をローカルに定義することもできます。 |
target | これは,ターゲット・システムまたはサーバの完全修飾ホスト名です。 たとえば miami.cities.dec.com のようになります。 このホスト名には 1 つまたは複数のアドレス・レコードが必要です。 名前として別名は使用できません。 このドメインでサービスがまったく使用できないことを示す必要がある場合は,target の値にピリオド (.) を指定します。 |
SRV エントリの例を次に示します。
;_service._protocol.name entry priority weight port target _ldap._tcp SRV 0 1 389 whitepages2.crimson.com. SRV 0 3 389 whitepages.crimson.com. SRV 1 0 389 zeus.crimson.com.
この例で,3 つの SRV エントリは,crimson.com ドメインで LDAP (Lightweight Directory Access Protocol) がサポートされていることを示しています。 このドメインのプライマリ LDAP サーバは whitepages と whitepages2 です。 これらのサーバは優先順位が同じですが,whitepages の方が新しく高速なサーバであるため,管理者は重みの値を大きくしています。 その結果,whitepages はドメインに対するディレクトリ照会の大多数を処理することになります。
プライマリ LDAP サーバがどちらも使用できない場合,クライアントは zeus サーバへの照会に切り替えます。
このサーバはドメイン内のさまざまなサーバをバックアップしています。
G.2.17 WKS (Well Known Services) エントリ
WKS (Well Known Services) エントリは,サービス位置 (SRV) エントリに置き換えられましたが,旧バージョンとの互換性のため残されています。
WKS エントリは,特定のプロトコルによってサポートされる周知のサービスを記述します。
サービスおよびポート番号は,/etc/services
ファイルで指定されているサービスのリストから取得されます。
WKS エントリのフォーマットを次に示します。
name ttl addr-class entry-type address protocol services
WKS エントリの各フィールドには,G.1 節で説明する値が入りますが,次のフィールドは例外です。
フィールド | 説明 |
address | このフィールドには,各システムの IP アドレスを指定します。 1 つのアドレスでは,プロトコルごとの WKS エントリは 1 つだけです。 |
protocol | このフィールドには,使用するプロトコル,たとえば,TCP や UDP を指定します。 |
2 つの WKS エントリの例を次に示します。
;name ttl addr-class entry-type address protocol services IN WKS 128.32.0.4 UDP who route IN WKS 128.32.0.78 TCP (echo talk discard sunrpc sftp uucp-path netstat host systat daytime link auth time ftp nntp whois pop finger smtp supdup domain nameserver chargen)
この例では,両方のエントリの 1 番目と 2 番目のフィールドが空白で,前のエントリで指定されているドメイン名と,SOA エントリまたは $ttl エントリで指定されている省略時の ttl が使用されます。 2 番目のエントリにリストされているサービスは,複数行にわたって記述されていますがカッコで囲まれているので 1 つのエントリとして解釈されます。