Solaris ネーミングの管理

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

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

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


タイプ	説明
SOA	権限の開始
NS	ネームサーバー
A	インターネットアドレス (名前からアドレス)
PTR	ポインタ (アドレスから名前)
CNAME	正規名 (ニックネーム)
TXT	テキスト情報
WKS	既知サービス
HINFO	ホスト情報
MX	メール交換

SOA - 権限の開始

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

例 27-1 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 つだけ指定してください。例 27-2 に SOA リソースレコードの例を示します。

例 27-2 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 - ネームサーバー

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

例 27-3 NS レコードフォーマット

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

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

例 27-4 NS リソースレコードの例

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

A アドレス

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

例 27-5 アドレスレコードの書式

	
machinename	[optional   TTL] class A	address

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

例 27-6 アドレスレコードの例

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

HINFO - ホスト情報

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

例 27-7 HINFO レコードの書式

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

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

例 27-8 HINFO リソースレコードの例

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

注意 -

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

WKS - 既知サービス

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

例 27-9 WKS レコードの書式

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

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

例 27-10 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 - 正規名

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

例 27-11 CNAME レコードの書式

 nickname [optional   TTL] class CNAME	canonical-name

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

例 27-12 CNAME リソースレコードの例

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

PTR - ポインタレコード

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

例 27-13 PTR レコードの書式

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

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

例 27-14 PTR リソースレコードのサンプル

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

MX - メール交換

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

例 27-15 MX リソースレコードの書式

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

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

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

例 27-16 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.