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

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

権限の開始レコード (SOA)

例 5–19 に権限の開始 (SOA) リソースレコードの構文を示します。

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

例 5–20 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)

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

例 5–21 NS レコードの書式

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

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

例 5–22 NS リソースレコードの例

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

アドレス (A)

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

例 5–23 アドレス (A) レコードの書式

	
machinename	[optional TTL] class A	address

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

例 5–24 アドレスレコードの例

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

ホスト情報 (HINFO)

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

例 5–25 HINFO レコードの書式

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

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

例 5–26 HINFO リソースレコードの例

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

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

既知サービス (WKS)

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

例 5–27 WKS レコードの書式

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

WKS レコードは、指定されたアドレスの特定のプロトコルでサポートされているよく知られたサービスを示します。 サービスのリストとポート番号は、services データベースで指定されたサービスのリストから得られます。 WKS レコードは、各アドレスの各プロトコルに 1 つだけ存在している必要があります。 例 5–28 に、WKS リソースレコードの例を示します。

例 5–28 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)

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

例 5–29 CNAME レコードの書式

 nickname [optional TTL] class CNAME	canonical-name

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

例 5–30 CNAME リソースレコードの例

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

ポインタレコード (PTR)

例 5–31 に、PTR リソースレコードの構文を示します。

例 5–31 PTR レコードの書式

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

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

例 5–32 PTR リソースレコードの例

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

メール交換 (MX)

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

例 5–33 MX レコードの書式

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

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

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

例 5–34 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.