Show Table of Contents
14.2.2. ゾーンファイルの編集
「ネームサーバーのゾーン」 に要約してあるように、ゾーンファイルにはネームスペースの情報が含まれています。情報はデフォルトで
/var/named/ にある named 作業ディレクトリに保存されます。そして各ゾーンファイルは zone ステートメント内の file オプションに従って命名されます。通常は、example.com.zone などのように該当するドメインに関連しながら、ゾーンデータを含むファイルとして識別できる方法で命名されます。
表14.5 named サービスのゾーンファイル
| パス | 詳細 |
|---|---|
/var/named/ | named サービスの作業ディレクトリです。ネームサーバーにはこのディレクトリに書き込む許可が ありません。 |
/var/named/slaves/ | セカンダリゾーンのディレクトリです。このティレクトリは named サービスによる書き込みが可能です。 |
/var/named/dynamic/ | 動的 DNS (DDNS) ゾーン、または管理された DNSSEC キーなどの他のファイル用のディレクトリです。このディレクトリは named サービスによる書き込みが可能です。 |
/var/named/data/ | 様々な統計とデバッギングファイル用のディレクトリです。このディレクトリは named サービスによる書き込みが可能です。 |
ゾーンファイルは指示文とリソースの記録で構成されています。指示文はネームサーバーに対してタスクを実行するか、または特別なセッティングをゾーンに適用するように指示し、リソースレコードはゾーンのパラメータを定義して識別子を個々のホストに割り当てます。指示文はオプションですが、リソースレコードはゾーンにネームサービスを提供するために必須です。
指示文とリソースレコードはすべて、個々の行内に入れる必要があります。
14.2.2.1. 一般的な指示文
指示文はドルマーク文字で始まり、その後に指示文の名前が続きます。そして通常、ファイルの最上部に現れます。以下の指示文は一般的にゾーンファイルで使用されます:
-
$INCLUDE $INCLUDE指示文により、それが出現する場所にもう１つのファイルを含めることができるため、他のゾーンセッティングは別個のソーンファイルに保存できるようになります。例14.7 $INCLUDE 指示文の使用
$INCLUDE /var/named/penguin.example.com
-
$ORIGIN $ORIGIN指示文により、ホスト名だけの非完全修飾型の記録へドメイン名を追記できるようになります。ゾーン名はデフォルトで使用されるため/etc/named.conf内でゾーンが指定されている場合は、この指示文の使用は必要ありません。例14.8「$ORIGIN 指示文の使用」 では、リソースレコード内で使用される名前でトレーリングピリオドで終了していない名前はいずれもexample.comが追記されています。例14.8 $ORIGIN 指示文の使用
$ORIGIN example.com.
-
$TTL $TTL指示文により、ゾーン用のデフォルト TTL (Time to Live) 値をセットできるようになります。即ちゾーン記録が有効である時間の長さのセッティングです。各リソースレコードはそれ自身のTTL 値を含むことができるため、それがこの指示文を上書きします。この値を増加させることにより、リモートのネームサーバーはより長い期間でゾーン情報をキャッシュ化することが出きるため、ゾーンへのクエリ回数が減少でき、リソースレコード変更の伝達に必要な時間を延長させることができます。例14.9 $TTL 指示文の使用
$TTL 1D
14.2.2.2. 一般的なリソースレコード
以下のリソースレコードは一般的にゾーンファイル内で使用されます:
-
A - Address レコードは名前に割り当てられる IP アドレスを指定します。以下の形式を取ります:
ホスト名 IN A IP-アドレス
hostname の値が欠如している場合、レコードは最後に指定された hostname を指します。例14.10 A ソースレコードの使用
server1 IN A 10.0.1.3 IN A 10.0.1.5 -
CNAME - Canonical Name (別名) レコードは１つの名前を別の名前にマップします。このため、このタイプのレコードは時々、エイリアスレコードと呼ばれています。以下の形式を取ります:
エイリアス名 IN CNAME 本当の名前
CNAMEレコードは Web サーバー用のwwwのように、共通の命名基準を使用するサービスを指すために最も一般的に使用されます。しかし、それらの使用については複数の制限が存在します:- CNAME レコードは他の CNAME レコードを指してはいけません。これは主に無限のループの可能性を避けるためです。
- CNAME レコードは他のリソースレコードタイプ (例えば、A, NS, MX, など) を含んではいけません。唯一の例外は、ゾーンが署名されている時の DNSSEC 関連のレコード (即ち、RRSIG, NSEC など) です。
- ホストの完全修飾型ドメイン名 (FQDN) を指す他のリソースレコード (即ち、NS, MX, PTR) は CNAME レコードを指してはいけません。
例14.11「CNAME リソースレコードの使用」 では、Aレコードがホスト名を IP アドレスにバインドして、CNAMEレコードが一般的に使用されるwwwホスト名をそれに対して指しています。例14.11 CNAME リソースレコードの使用
server1 IN A 10.0.1.5 www IN CNAME server1
-
MX - Mail Exchange レコードは、このゾーンによって制御されている特定のネームスペースに送信されるメールの行き先を指定します。以下の形式を取ります:
IN MX preference-value email-server-name
email-server-name は完全修飾型ドメイン名 (FQDN) です。preference-value によってネームスペースのメールサーバーの数値ランキングが可能になり、一部のメールシステムに他のシステムよりも優先度を与えます。最小の preference-value を持つMXリソースレコードが他よりも優先されます。しかし複数メールサーバーが同じ値を持つ可能性があり、その場合はメールトラフィックをサーバー間で均等に分配することになります。例14.12「MX リソースレコードの使用」では、example.comドメイン宛のメール受信時には最初のmail.example.comメールサーバーがmail2.example.comメールサーバーよりも優先されます。例14.12 MX リソースレコードの使用
example.com. IN MX 10 mail.example.com. IN MX 20 mail2.example.com. -
NS - Nameserver レコードはある特定のゾーン用に正当なネームサーバーを表明します。以下の形式を取ります:
IN NS nameserver-name
nameserver-name は完全修飾型ドメイン名 (FQDN) である必要があります。ドメインに対して２つのネームサーバーが正当だとして一覧表示されている時には、これらのネームサーバーがセカンダリネームサーバーであるか、またはその１つがプライマリサーバーであるかどうかは重要でありません。両方とも正当と考慮されます。例14.13 NS リソースレコードの使用
IN NS dns1.example.com. IN NS dns2.example.com.
-
PTR - Pointer レコードはネームスペースの別の部分を指します。以下の形式を取ります:
last-IP-digit IN PTR FQDN-of-system
last-IP-digit 指示文は IP アドレスの末尾の番号です。そしてFQDN-of-system は完全修飾型ドメイン名 (FQDN) です。 -
SOA - Start of Authority レコードはネームスペースについての信頼できる重要な情報をネームサーバーに表明します。指示文の後に配置されていて、ゾーンファイルでは最初のリソースレコードです。以下の形式を取ります
@ IN SOA primary-name-server hostmaster-email ( serial-number time-to-refresh time-to-retry time-to-expire minimum-TTL )指示文は以下の通りです:@シンボルは$ORIGIN指示文 (または$ORIGIN指示文がセットされていない場合は、ゾーン名) をこのSOAリソースレコードで定義されたネームスペースとして配置します。- primary-name-server 指示文は、このドメイン用に正式となるプライマリネームサーバーのホスト名です。
- hostmaster-email 指示文は、ネームスペースに関して連絡する相手のメールです。
- serial-number 指示文は、
namedサービスがゾーンを再ロードする時間であることを示すためにゾーンファイルが変更される度に増加する数値です。 - time-to-refresh 指示文は、ゾーンに対して変更がなされたかどうかをプライマリネームサーバーに尋ねるまで待機する時間の長さを決定するためにセカンダリネームサーバーが使用する数値です。
- time-to-retry 指示文は、プライマリネームサーバーが応答しない事態にリフレッシュ要求を出すまで待機する時間の長さを決定するためにセカンダリネームサーバーによって使用される数値です。time-to-expire 指示文内で指定された時間が経過するまでに、プライマリネームサーバーがリフレッシュ要求に応答しない場合は、セカンダリサーバーはそのネームスペースに関する要求での権威としての応答を停止します。
- BIND 4 と 8 では、minimum-TTL 指示文は他のネームサーバーがゾーンの情報をキャッシュ化する時間の長さです。BIND 9 では、これは否定的な回答がキャッシュ化される時間の長さを定義します。否定的回答のキャッシュ化は最大で３時間にセットできます (即ち
3H)。
BIND を設定する時、すべての時間は秒で指定されます。しかし、秒以外の時間単位を指定するのに短縮形を使用することができます。例えば、分 (M)、時間 (H)、日 (D)、及び週 (W) とします。表14.6「秒表示とその他の時間単位」 では、時間数を秒で示し、更にはその同時間を他の形式で示しています。表14.6 秒表示とその他の時間単位
秒 他の時間単位 60 1M1800 30M3600 1H10800 3H21600 6H43200 12H86400 1D259200 3D604800 1W31536000 365D例14.14 SOA リソースレコードの使用
@ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day
14.2.2.3. コメントタグ
リソースレコードと指示文の他にも、ゾーンファイルもコメントを格納することができます。コメントは
named サービスでは無視されますが、ユーザーに追加情報を提供する際に便利です。セミコロンの後の行末までのテキストはすべてコメントとみなされます。例えば:
604800 ; expire after 1 week
14.2.2.4. 使用法の例
下記の例は、ゾーンファイルの基本的使用法を示したものです。
14.2.2.4.1. 単純なゾーンファイル
例14.15「単純なゾーンファイル」 では、標準の指示文と
SOA 値の使用を提示しています。
例14.15 単純なゾーンファイル
$ORIGIN example.com.
$TTL 86400
@ IN SOA dns1.example.com. hostmaster.example.com. (
2001062501 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
;
;
IN NS dns1.example.com.
IN NS dns2.example.com.
dns1 IN A 10.0.1.1
IN AAAA aaaa:bbbb::1
dns2 IN A 10.0.1.2
IN AAAA aaaa:bbbb::2
;
;
@ IN MX 10 mail.example.com.
IN MX 20 mail2.example.com.
mail IN A 10.0.1.5
IN AAAA aaaa:bbbb::5
mail2 IN A 10.0.1.6
IN AAAA aaaa:bbbb::6
;
;
; This sample zone file illustrates sharing the same IP addresses
; for multiple services:
;
services IN A 10.0.1.10
IN AAAA aaaa:bbbb::10
IN A 10.0.1.11
IN AAAA aaaa:bbbb::11
ftp IN CNAME services.example.com.
www IN CNAME services.example.com.
;
;
この例では、正式なネームサーバーは
dns1.example.com と dns2.example.com としてセットされており、A を使用して 10.0.1.1 と 10.0.1.2 の IP アドレスに結合されています。
MX レコードで設定されているメールサーバーは、A レコードを介して mail と mail2 に向けられています。これらの名前はトレーリングピリオドで終了していないため、$ORIGIN ドメインがその後に配置されており、それらを mail.example.com および mail2.example.com に広げています。
www.example.com (WWW) などの標準の名前で利用可能なサービスは、CNAME レコードを使用して適切なサービスを指すようにしてあります。
このゾーンファイルは、
/etc/named.conf 内で zone ステートメントを持つサービスに呼ばれることになります。以下に似ています:
zone "example.com" IN {
type master;
file "example.com.zone";
allow-update { none; };
};14.2.2.4.2. 逆引き名前解決ゾーンファイル
逆引き名前解決ゾーンファイルは、特定のネームスペース内の IP アドレスを完全修飾型ドメイン名 (FQDN) に解決するのに使用されます。例14.16「逆引き名前解決ゾーンファイル」 に示してあるように、これは標準のゾーンファイルに非常に似ていますが、
PTR リソースレコードは IP アドレスを完全修飾型ドメイン名にリンクするために使用されます。
例14.16 逆引き名前解決ゾーンファイル
$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
@ IN SOA dns1.example.com. hostmaster.example.com. (
2001062501 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
;
@ IN NS dns1.example.com.
;
1 IN PTR dns1.example.com.
2 IN PTR dns2.example.com.
;
5 IN PTR server1.example.com.
6 IN PTR server2.example.com.
;
3 IN PTR ftp.example.com.
4 IN PTR ftp.example.com.
この例では、
10.0.1.1 から 10.0.1.6 までの IP アドレスは該当する完全修飾型ドメイン名を指しています。
このゾーンファイルは
/etc/named.conf ファイル内の zone ステートメントを持つサービスに呼ばれることになります。以下に似ています:
zone "1.0.10.in-addr.arpa" IN {
type master;
file "example.com.rr.zone";
allow-update { none; };
};
この例と標準の
zone ステートメントとの間には少ししか相違がありませんが、ゾーン名は異なります。逆引き名前解決ゾーンは、IP アドレスの最初の３つのブロックが逆になっていて、その後に .in-addr.arpa が続く必要があります。これにより、逆引き名前解決ゾーンファイルで使用される IP 番号のシングルブロックがそのゾーンと関連付けされるようになります。
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.