test

Solaris ネーミングの管理

データファイルのリソースレコード書式

DNS のデーモン in.named によって使用されるすべてのデータファイルは標準リソースレコード書式で書かれます。各 DNS データファイルには、必ずリソースレコードが含まれる必要があります。ここでは、DNS データファイルと各ファイルに含まれるべきリソースレコードについて説明します。

標準リソースレコード書式

標準リソースレコード書式では、データファイルの各行は、「リソースレコード」(RR) と呼ばれます。リソースレコードには空白で区切られた次のようなフィールドがあります。 


namettl			class		record-type				record-specific-data

フィールドの順は常に同じですが、最初の 2 行はオプション (カッコ付きで示す) です。また、最後は record-type フィールドによって変化します。

name フィールド

最初のフィールドは、そのレコードに適用するドメイン名のフィールドです。RR でこのフィールドが空白のままであれば、デフォルトとして直前の RR の name フィールドの値が用いられます。

ゾーンファイルのドメイン名は、ドットで終わる完全指定名でも、相対名でもかまいません。相対名の場合、現在のドメインが相対名に付加されます。

ttl フィールド

2 番目のフィールドは、オプションの有効期限フィールドです。このフィールドで、データを破棄する前にデータベース内にデータをキャッシュに保存しておく時間 (秒)、すなわちサーバーに新しい情報を次回リクエストするまでの時間を指定します。このフィールドを空白のままにすると、ttl には、Start-Of-Authority (SOA) リソースレコードで指定された最小時間がデフォルトとして用いられます。

ttl の設定値があまりにも小さいと、サーバーはデータ更新のためのリクエストを頻繁に繰り返します。逆に、ttl の設定値があまりにも大きいと、情報の変更がタイムリーに反映されなくなります。

ほとんどの場合、ttl の値は、初期値として 1 日 (86400) から 1 週間 (604800) の間に設定するとよいでしょう。実際の情報の変更の頻度にあわせて、ttl の値を適切な値に変更してください。また、ほとんど変化することがないデータと関連しているということで ttl の値を大きく設定していた場合、そのデータが変更されるとわかった時点で、ttl の値を、データの変更があるときまで小さな値 (3600 から 86400) にし、その後またもとの大きな値に戻すこともできます。

同じ名前、クラス、タイプを持つすべての RR では、ttl は同じ値に設定してください。

class フィールド

3 番目のフィールドは、レコードのクラスです。現在のところ、1 つのクラスだけがあります。それは、TCP/IP プロトコルのファミリーであることを示す IN です。

record-type フィールド

4 番目のフィールドでは、リソースレコードのタイプを記述します。RR にはたくさんのタイプがあります。最も一般的に使用されるタイプは、「リソースレコードのタイプ」で説明されています。

record-specific-data フィールド

record-specific-data フィールドの中身は、特定のリソースレコードのタイプで異なります。

ネームフィールドやデータフィールドの大文字と小文字の区別は、ネームサーバーに読み込まれたときには保存されていますが、ネームサーバーのデータベースを比較して検索する際には大文字と小文字の区別はしません。しかし、これは将来的には変更される可能性がありますので、大文字と小文字の使用に関しては一貫性を保つように心がけてください。

特殊なリソースレコード文字

次に挙げる文字には特別な意味があります。

表 28-4 特別な意味を持つリソースレコード文字

文字 

定義 

.

ネームフィールドで、1 つのドットだけが指定された場合は現在のドメインを指す 

@

ネームフィールドで、1 つの @だけが指定された場合は現在の起点を示す

..

2 つのドットがネームフィールドに指定された場合は null ドメイン名を表す 

¥X

X は数字以外 (0-9) の任意の文字で、¥ を付けることによって文字に特別な意味を持たせないようにする。たとえば、¥. を指定して、ラベル内にドット文字おくことができる

¥DDD

各 D は一桁の数字で、¥ を付けることによって DDD で表される 10 進数に対応する 8 進数を表現する。結果的に得られる 8 進数は、テキストとみなされ、そのテキストに特別な意味があるかどうかはチェックされない

()

データが 1 行に収まらないようなとき、データをグループ化するのにカッコを使用する。結果的に、カッコの間では行の終わりが認識されない 

;

セミコロンでコメントが開始する。その行でセミコロン以降は無視される 

*

アスタリスクはワイルドカードを表す 

ほとんどのリソースレコードには、現在の起点があり、名前の最後にドット (.) が付いていなければ、現在の起点が名前に追加されます。この機能は、マシン名などのデータに現在のドメイン名を追加する際には便利ですが、追加したくない場合には、問題を引き起こすかもしれません。データファイルを作成しているドメイン内に名前がない場合、ピリオドで終わる完全指定名を使してください。

制御エントリ

データファイルで制御エントリの行だけは標準 RR 書式に従わない行です。制御エントリには、$INCLUDE() と $ORIGIN()の 2 つのタイプがあります。

$INCLUDE

インクルード行は 1 列目から $INCLUDE で始まり、後にファイル名 ($INCLUDE ファイル) が続きます。次の例に示すように、この機能は異なるタイプのデータを複数のファイルに分けるのに特に便利です。


$INCLUDE /etc/named/data/mailboxes

この行は、/etc/named/data/mailboxes ファイルを読み込むリクエストとして解釈されます。$INCLUDE コマンドでは、異なるゾーンまたはツリーにデータは読み込まれません。このコマンドを使用しても、あるゾーンのデータを別々のファイルに入れるだけです。たとえば、mailbox のデータはこの機能を使ってホストデータとは別に保存されます。

$INCLUDE の文とファイルは必要に応じて必要な数だけ使用できます。

$ORIGIN()

$ORIGIN コマンドによって、データファイル内の起点を変更できます。この行は 1 列目から始まり、ドメイン名が続きます。これによって、相対ドメイン名 (たとえば、完全指定されていないドメイン名) の現在の起点を指定の名前に変更します。これは、1 つのデータファイルに複数のドメインを入れるのに便利です。

注 -

1 つのデータファイルに複数のゾーンを入れるために $ORIGIN() を使うことはできません。

データファイルでの $ORIGIN コマンドは、必要に応じて使用します。もし、$ORIGIN() 文がない場合、DNS データファイルのデフォルトの起点は named.conf ファイルの primary または secondary の行の 2 番目のフィールドにあるドメイン名です。

リソースレコードのタイプ

最も一般的に使用されるリソースレコードのタイプを 表 28-5 に列挙します。通常、表 28-5 に並んだ順で入力しますが、必須というわけではありません。

表 28-5 一般的に利用されるリソースレコードのタイプ

タイプ 

説明 

SOA 

権限の開始 

NS 

ネームサーバー 

A 

インターネットアドレス (名前からアドレス) 

PTR 

ポインタ (アドレスから名前) 

CNAME 

正規名 (ニックネーム) 

TXT 

テキスト情報 

WKS 

既知サービス 

HINFO 

ホスト情報 

MX 

メール交換 

SOA - 権限の開始

例 28-2 に SOA リソースレコードの構文を示します。

例 28-2 SOA レコードの書式


name class SOA origin person-in-charge ( serial number
		refresh
	retry
	expire
	ttl)

権限の開始 (SOA) レコードでゾーンの開始を指定します。次の SOA レコードでそのゾーンは終了します。次に SOA レコードのフィールドについて述べます。

name

ゾーン名を指定します。ゾーン名の後にはドットを付ける必要があります。たとえば、doc.com. は正しいですが、一方、doc.com は誤りです。

class

アドレスのクラスです。たとえば、IN は、インターネットを示し、最も一般的に用いられるクラスです。

SOA

リソースレコードのタイプを示します。

origin

データファイルがあるホスト名のフィールドです。ホスト名の後にはドットを付ける必要があります。たとえば、dnsmaster.doc.com. は正しいですが、dnsmaster.doc.com は誤りです。

person-in-charge

ネームサーバーの責任者のメールアドレスのフィールドです。たとえば、kjd.nismaster.doc.com. です。この名前も終わりにドットを付ける必要があります。

serial

データファイルのバージョン番号のフィールドです。データを変更するたびにこの番号を増やしてください。副サーバーは serial フィールドを使って、最後にマスターサーバーからデータファイルをコピーしたときから変更があったかどうかを検出します。

refresh

更新が必要かどうかを見るために副ネームサーバーがどのくらいの頻度で主ネームサーバーをチェックすべきかを秒で指定します。たとえば、7200 は、2 時間を意味します。

retry

リフレッシュのためのチェックに失敗した後、副サーバーがどのくらいの時間再試行するかを秒で指定します。

expire

リフレッシュが頻繁に行われない場合に、データの期限が切れる前に、副ネームサーバーがそのデータを使用する上限の時間を秒で指定します。

ttl

リソースレコードの time-to-live フィールドで使用されるデフォルトの秒数を指定します。このデフォルト値はリソースレコードで ttl が指定されていないときに適用されます。

SOA は各ゾーンに 1 つだけ指定してください。例 28-3 に SOA リソースレコードの例を示します。

例 28-3 SOA リソースレコードの例


;name class 		SOA 	origin				 person-in-charge
doc.com. IN		SOA	dnsmaster.doc.com. root.nismaster.doc.com. (
							101			;Serial
							7200		;Refresh
							3600		;Retry
							432000		;Expire
							86400)		;Minimum			 )

NS - ネームサーバー

例 28-4 に、ネームサーバー (NS) リソースレコードの構文を示します。

例 28-4 NS レコードフォーマット


domainname [optional TTL] class NS name-server-name

ネームサーバーレコードには、対象としているドメインを受け持つサーバーの名前を指定します。name フィールドには、指定したネームサーバーからサービスを受けるドメインを指定します。もし、name フィールドが指定されない場合、そのデフォルトは最後に指定された名前になります。そのドメインの主マスターサーバーと副マスターサーバーのそれぞれに 1 つの NS レコードが必要です。例 28-5 に NS リソースレコードの例を示します。

例 28-5 NS リソースレコードの例


;domainname    [TTL] 	 class	NS	nameserver
doc.com        90000    IN	NS 	sirius.doc.com.

A アドレス

例 28-6 に、アドレス (A) リソースレコードの構文を示します。

例 28-6 アドレスレコードの書式


	
machinename	[optional TTL] class A	address

アドレス (A) レコードでは、対象としているマシンのアドレスを指定します。name フィールドは、ホスト名のフィールドです。address は、IP アドレスです。各マシンのアドレスに 1 つの A レコードが必要です。ルーターやゲートウェイには 2 つ以上のエントリが必要で、IP アドレスを含む別々のエントリがネットワークインタフェースに必要です。

例 28-7 アドレスレコードの例


;machinename	[TTL]	class	A	address
sirius		IN		A	123.45.6.1

HINFO - ホスト情報

例 28-8 に、ホスト情報 (HINFO) リソースレコードの構文を示します。

例 28-8 HINFO レコードの書式


[optional name] [optional TTL] 	class	HINFO hardware	OS

ホスト情報 (HINFO) リソースレコードでは、ホスト固有のデータを指定します。ハードウェアとこのホストで動作しているオペレーティング環境を指定します。マシン名や hardware フィールドのエントリに空白を含めるには、エントリを引用符で囲む必要があります。name フィールドでは、ホスト名を指定します。名前が指定されなければ、in.named での最後のホストがデフォルトになります。各ホストに1 つの HINFO レコードが必要です。例 28-9 に HINFO リソースレコードの例を示します。

例 28-9 HINFO リソースレコードの例


;[name]   [TTL] class HINFO   hardware    OS
                IN    HINFO   Sparc-10    UNIX
注意 - 注意 -

HINFO フィールドにはネットワーク上のマシンについての情報があるので、多くのサイトで、この情報はセキュリティ上危険であると考えられ、現在はほとんど使われていません。

WKS - 既知サービス

例 28-10 に、既知サービス (WKS) リソースレコードの構文を示します。

例 28-10 WKS レコードの書式


[Optional name] [TTL] class WKS address protocol-list-of-services

既知サービス (WKS) レコードには、指定されたアドレスの特定のプロトコルでサポートされるよく知られたサービスが記述されます。サービスのリストとポート番号はサービスデータベースで指定されたサービスのリストから得られます。各プロトコルの各アドレスに 1 つの WKS レコードが必要です。例 28-11 に WKS リソースレコードの例を示します。

例 28-11 WKS リソースレコードの例


;[name]	[TTL]	class	WKS	address 	 protocol-list-of-services
altair	IN	WKS	123.45.6.1	 TCP ( smtp discard rpc
                                                 sftp uucp-
path systat daytime
 						 netstat qotd nntp doc.com )
注意 - 注意 -

WKS レコードはオプションです。セキュリティ上の理由から、ほとんどのサイトでは現在この情報は提供していません。

CNAME - 正規名

例 28-12 に、正規名 (CNAME) リソースレコードの構文を示します。

例 28-12 CNAME レコードの書式


 nickname [optional TTL] class CNAME	canonical-name

正規名 (CNAME) リソースレコードでは、正規名に対するニックネームまたは別名を指定します。ニックネームは一意である必要があります。他のすべてのリソースレコードは、ニックネームではなく正規名と結びつけるようにする必要があります。ニックネームの作成と他のリソースレコードでの使用はしないでください。ニックネームは、マシン名が変更されたけれども古い名前でのアクセスを許可する移行期に特に有用です。また、ニックネームはメールサーバーなど特定の目的で使用するマシンを識別するためにも使用できます。例 28-13 に CNAME リソースレコードの例を示します。

例 28-13 CNAME リソースレコードの例


;nickname      [TTL]	class	CNAME	canonical-name
mailhost		IN	CNAME antares.doc.com

PTR - ポインタレコード

例 28-14 に、ポインター (PTR) リソースレコードの構文を示します。

例 28-14 PTR レコードの書式


 special-name	[optional TTL]  class	 PTR-real-name

特別名でドメイン内の他の場所を指すことが、ポインタレコードによって可能になります。例では、PTR は、アドレス (特別名) の実名への変換のために、主に in-addr.arpa. レコードで使用されます。アドレスを解釈するときは、ドメインが完全指定であれば、指定する必要があるのはマシンの識別番号だけです。PTR の名前付けは、ゾーンに対して一意である必要があります。PTR レコードによって特別なドメインである in-addr.arpa.ドメインに対する逆ポインタが設定 (例 28-15) されます。

例 28-15 PTR リソースレコードのサンプル


;special name   [TTL]	class	PTR-real-name
1			IN	PTR sirius.doc.com.

MX - メール交換

例 28-16 に、メール交換 (MX) リソースレコードの構文を示します。

例 28-16 MX リソースレコードの書式


name [optional TTL] class	MX preference-value mailer-exchanger

メール交換リソースレコードは、あるドメインまたはドメイン内の特定のマシンにメールを配信するマシンを指定するために使用します。対象としている名前に対して複数の MX リソースレコードがあるかもしれません。例 28-17 では、Seismo.CSS.GOV (完全指定のドメイン名) は、Munnari.OZ.AU にメールを配信するメールゲートウェイです。ネットワーク上の他のマシンは、Munnari に直接メールを配信できません。Seismo と Munnari は、専用接続を持っている場合も、異なるトランスポートメディアを使用している場合もあります。優先値フィールドで、メールプログラムが従うべき順を指定します。単一のマシンに複数の方法でメールが配信される場合に指定します。値が 0 (ゼロ) は最優先であることを意味します。同じ名前に対して複数の MX リソースレコードがある場合、そのレコードの優先値は同じであることも、同じでないこともあります。

メールをルーティングするために、MX レコードでワイルドカードであるアスタリスク ( *) を名前に使うこともできます。あるドメイン宛のメールはリレー経由で配信されることを単に示すサーバーがネットワーク上にはよくあります。例 28-17 では、foo.com ドメイン内のホスト宛のすべてのメールは RELAY.CS.NET. を経由して送られます。これを指定するには、ワイルドカードを用いて MX リソースレコードを作成し、*.foo.com のメール交換は RELAY.CS.NET. により行われると指定します。アスタリスクは foo.com の任意のホストまたはサブドメインに一致します。しかし、foo.com 自体には一致しません。

例 28-17 MX リソースレコードの例


;name	 	[TTL]	class		MX	 preference mailer-exchanger
Munnari.OZ.AU.	IN		MX	 0	Seismo.CSS.GOV.
foo.com.		IN		MX	 10	RELAY.CS.NET.
*.foo.com.	IN		MX	 20	RELAY.CS.NET.