Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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.example.com 用の要求は、10.0.1.3 または 10.0.1.5 を指しています。

例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) です。
PTR レコードは主に逆引き名前解決に使用されます。これは逆に IP アドレスから特定の名前を指します。PTR レコードの使用例については 「逆引き名前解決ゾーンファイル」 を参照して下さい。
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 1M
1800 30M
3600 1H
10800 3H
21600 6H
43200 12H
86400 1D
259200 3D
604800 1W
31536000 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 番号のシングルブロックがそのゾーンと関連付けされるようになります。