Tweet

前回作成したBIND DNS　マスターサーバのゾーン設定をたたき台として、SOAレコードの各種パラメータとゾーン転送を中心に説明します。 

ゾーンファイル

以下は、前回作成した２つのゾーンファイルの内容です。今回は、SOAレコードを中心に主要な設定項目を見ていくことにしましょう。

/var/named/zones_master_forward/eis.co.jp.zone

/var/named/zones_master_rev/rev_124.34.146.120_28.zone

必要なディレクティブとSOAレコード

ディレクティブ

$ORIGINディレクティブ

$ORIGIN ディレクティブは、それにつづくSOAレコード、Aレコード、PTRレコード等がの最後に「.（ドット）」のない名前を含む場合に、最後に付加される文字 列を定義します。また$ORIGINに設定した値そのものを名前として利用する場合、「@」で置き換えることができます。

$ORIGIN ディレクティブは、ひとつのゾーンファイルの中で複数回使用することができます。つまり、ひとつのゾーンファイルにすべてのゾーンを記述することも可能で す。今回の例では、それぞれのゾーンに別々なゾーンファイルをわりあてていますので、先頭の$ORIGINは省略できますが、わかりやすさのために、敢え て残しています。

$TTL

当該ゾーンの各レコードの寿命（Time To Live）の値を秒単位で指定します。前項の$ORIGINでゾーンを指定した直後は、かならず$TTLで、そのゾーンのデフォルトTTL値を指定する必 要があります。$TTLが指定されると、それに続くすべてのゾーンレコードのTTLがこの値となります。また$TTLは何回でも設定可能です。

$TTL の値は、このDNSサーバからゾーン情報を取得する他のサーバにより、取得した情報の有効期間として参照されます。マスターサーバ側でなんらかの変更を 行った際に、最大ここに指定した時間、他のサーバに更新が反映されない可能性があります。例では、3600秒=1時間です（かつてはもっと大きな値を設定 するのが一般的でしたが、サイトの成長の早い昨今では、この程度に短縮される傾向にあります）。

$TTLは、各レコード毎に指定することも可能です。DHCPとの連携でDDNSによりクライアントPCのDNS登録を自動化する場合などは、300秒=5分などという更に短い時間に設定する場合もあります。

SOAレコード

SOAは「Start Of Authority」の略です。「Start」は「権限のあるゾーンの記述がここから始まる」というような意味です。

SOAレコードの記述方法は以下のとおりです。<>内の名前はRFC1035（”DOMAIN NAMES – IMPLEMENTATION AND SPECIFICATION”）で採用されているパラメータ名です。

•  @
  先に述べたように、@は、直近の$ORIGINディレクティブで定義されたゾーン名をあらわしています（named.confで定義されたゾーンの ゾーンファイルであり、@以前に$ORIGINディレクティブがない場合には、named.confで指定したゾーンのゾーン名です）。「@」の代わり に、ゾーン名をそのまま書くことももちろん可能です。
• MNAME
  このゾーンのプライマリーDNSサーバを指定します。ホスト名をFQDNで設定します（末尾に「.」が必要です）。IPアドレスはだめです。ここに設定するホスト名は、AレコードでIPアドレスを定義したものでなければなりません（CNAMEで定義したホスト名はだめ）。
• RNAME
  こ のゾーンの責任者のメールアドレスをFQDNで設定します。具体的には、通常のメールアドレスのローカルパートとメールドメイン部の区切り文字である 「@」を、「.」におきかえた文字列です。MNAME同様、末尾に「.」をつけないと、ゾーン名が自動的に付加されてしまいます。メールアドレスのローカ ルパートが「.」を含むものである場合、そのドットの直前に「」記号を付加してエスケープします。
  教科書どうりですと、メールアカウントにはホ ストの管理者のメールアドレスの予約語である「hostmaster@<ホストのFQDN>」を使うのがセオリーですが、このアドレスには管 理者が送信されたメールを読むことが確実であるアドレスを設定します（トラブルやセキュリティに関する重要なメールが配信されることがあるそうです）。
• SERIAL
  ゾーン情報のシリアル番号（ヴァージョン番号）です。符号なし32ビットの数値で、更新毎に連番で加算されることが前提となっています。
• REFRESH
  つづくRETRY, EXPIREとともに、スレーブネームサーバによる更新チェックのタイミング等を決定する値のひとつです。
  REFRESH はスレーブサーバがゾーン情報の更新の有無（「SERIAL」の増加）をチェックする周期を秒単位で示す数値です。スレーブサーバに対して更新チェックの 目安として提示されます。チェックの結果、SERIALが増加していれば、スレーブサーバはゾーン転送によりゾーン情報を更新します。
• RETRY
  マスターサーバやネットワークの障害によりポーリングが失敗した際に、再試行の周期を秒単位であらわす数値です。原則としてREFRESHの値の整数分の１の値を設定します。
• EXPIRE
  マ スターサーバがダウンした場合、スレーブサーバはこの数値で提示された期間が経過するまでは、最後にマスターサーバから受け取ったゾーン情報を有効なもの としてサービスを継続しますが、期間満了とともにそのゾーン情報を無効として廃棄します。その後のこのゾーンに関するDNSクエリーはエラーとなります。
  値を決定する目安は、マスターサーバの予想される最大ダウンタイムよりも長い期間ということになります。RFC1912は、2～４週間（1209600～2419200）を推奨しています。
• MINIMUM
  各リソースレコード（A, MX, TXT etc.）のデフォルトのTTL（Time To Live=有効期間）を秒数で指定します。

ゾーン転送関連の設定値を考える

シリアル番号の推奨値と管理

シリアル番号の推奨値

ネームサービスの仕様を定義したRFC1035に従えばSERIALはあくまで1から始まる連番ですが、運用面では、RFC1912は、 YYYYMMDDnn（nnは当該日の連番）の形態に見立ててこの数値を管理することを推奨しています。SERiALの値は数値として符号なし32ビット の範囲に収り、更新毎に増加する値であれば良いわけです。実際、この書式で西暦4294年までは桁あふれしません（そのころにDNSサービスが今のままあ るのかは知る由もありません）。

ただし、DHCP連携等によるDDNSとして利用する場合や、ゾーン情報の編集に管理ツール等を使用した場 合、シリアル番号は、RFC1035の定義どおりの単なる数値として扱われ、ゾーン情報の更新毎に単純に１が加算され ます。したがって、この場合はYYYYMMDDnnを初期値とすることに意味がありません。