G    DNS データ・ファイル・エントリのフォーマット

DNS (Domain Name System) の構成ファイルは,省略時の設定では /etc/namedb/named.boot という名前で作成され,DNS データ・ファイルの名前を指定します。 これらのデータ・ファイルは,この章で説明するフォーマットのエントリで構成されます。 データ・ファイル・エントリのことをリソース・レコード (RR) とも呼びます。

G.1    DNS リソース・レコードのフォーマット

DNS リソース・レコードの一般的なフォーマットは次のとおりです。

name     ttl     addr-class     entry-type    entry-specific-data

各フィールドは次のように定義されています。

フィールド 説明
name

このフィールドには,たとえば cities.dec.com のような,ドメインの名前を指定します。 最初のカラムはドメイン名で開始する必要があります。

データ・ファイル・エントリによっては,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    データ・ファイル・エントリの説明

次の項では,それぞれのデータ・ファイル・エントリとそのフォーマットについて説明します。

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.
 

G.2.3    TTL エントリ

格納時間エントリは,他のリソース・レコードの 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

G.2.4    アドレス・エントリ

アドレス (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.

G.2.7    ホスト情報エントリ

ホスト情報 (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.

G.2.14    ドメイン名ポインタ・エントリ

ドメイン名ポインタ (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 ビットのニブルを逆順にピリオドで区切ったものにサフィックス.IP6.INT を付加したもので表記します。

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 つのエントリとして解釈されます。