強いBIND DNSサーバを構築する　第五回　- SOAレコードとゾーン転送

ゾーンファイル

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

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

$ORIGIN eis.co.jp.
$TTL 3600       ; 1 hour
@	IN SOA  ns1.eis.co.jp. postmaster.eis.co.jp. (
        2009082401 ; serial
        3600       ; refresh (1 hour)
        1200       ; retry (20 min.)
        1209600    ; expire (2 weeks)
        900        ; minimum (15 min.)
        )
@		IN  NS		ns1.eis.co.jp.
@		IN  NS		ns2.eis.co.jp.
@		IN  MX		10  mail.eis.co.jp.
@		IN  TXT		"v=spf1 mx ~all"    ; SPF record

ns1		IN  A           124.34.146.121
ns2		IN  A           124.34.146.122
mail		IN  A           124.34.146.123
server4		IN  A           124.34.146.124
www		IN  CNAME  server4

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

$ORIGIN   120/28.146.34.124-in-addr.arpa.
$TTL 3600
@	IN SOA    ns1.eis.co.jp.  postmaster.eis.co.jp. (
        2009082401; serial
	3600      ; refresh (1 hour)
        1200      ; retry (20 min.)
        1209600   ; expire (2 weeks)
        900       ; minimum (15 min.)
        )

121               IN   PTR    ns1.eis.co.jp.
122               IN   PTR    ns2.eis.co.jp.
123               IN   PTR    mail.eis.co.jp.
124               IN   PTR    server4.eis.co.jp.

主要なディレクティブと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を初期値とすることに意味がありません。

シリアル番号を間違えたときの対策

シリアル番号に誤った値を設定してDNSサービスの再起動を行ってしまう場合があります。

誤って小さい値を設定した場合

それまでの数値よりも小さな値を設定した場合、スレーブサーバは自身の持つゾーン情報よりもマスターサーバのゾーン情報が古いと判断し、ゾーン情報の更新を行いません。この場合は、シリアル番号を正しく設定しなおし、DNSサービスの再起動えば補正は完了します。

誤って大きな値を設定した場合

それまでの値よりも大きな数値を設定した場合、ゾーン情報の更新は正常に行われます。ただし、YYYYMMDDnnの形態で管理をし、誤って未来の数値を設定してしまった場合、シリアルの数値はもはや正しい日付を表していません。例えば、2009082401のはずが、2009092401と入力してしまった場合です。この場合、以下の手順でわざと桁あふれを起こさせた後に正しい値を設定して補正することができます。

1. 誤って設定した値に2147483647を加算する。結果が4294967296（符号なし32ビットの最大値）を超えない場合は、そのままの値を。超えた場合は結果から4294967296を引いた値を、シリアル番号として設定し、namedを再起動する。
2. この状態で、<REFRESH>2周期分以上待って、1の設定結果がすべてのスレーブサーバに伝播するのを待つ。
3. シリアル番号を本来の値に変更し、namedを再起動する。

参考：この方法はRFC1912に提案されています。

REFRESH, RETRY, MINIMUM

REFESH/RETRYは、スレーブサーバのマスターサーバに対するゾーン情報更新のポーリングの周期を決定します。スレーブサーバはマスターサーバの各ゾーンのシリアル番号を周期的にチェックし、増えていれば、ゾーン転送を行います。<REFRESH>はこの周期を秒単位で指定するものです。ポーリングの頻度を上げれば、スレーブサーバの情報の鮮度は向上しますが、スレーブサーバの負荷が増大します。スレーブサーバが数百、数千といった多数のゾーンのスレーブを担当している場合、すべてのマスターサーバの「わがままな要求」に対応できるかどうかが問題になってきます。REFRESH, RETRYの数値は、マスター/スレーブ両者の都合を考慮して決定すべき性格のものです。

RFC1912の推奨値と実際

WEBサーバ、メールサーバそれぞれ一台またはオールインワンサーバで、数年にわたってIPアドレスやホスト名の変更がないといったサーバを前提条件として、RFC1912は、以下の設定を推奨しています。

REFRESH/RETRY

ポーリングによる多少のバンドワイズの低下が気にならないネットワークでは20分～2時間、ダイアルアップなどオンデマンドのネットワーク接続の場合、2～12時間というのがRFC1912で推奨されている値です（回線によっては課金が発生します）。

一定規模以上のサイトでは、ホストの増設や老朽化による入れ替えに伴うゾーン情報の変更は頻繁に発生します。REFRESHの周期は短いほどスレーブサーバへの更新の反映はよりタイムリーになります。十分事前に計画的に一時REFRESH/RETRYの設定値を大幅に減少させるという対応も考えられますが、大規模なネットワークではいちいちこのような対応をしていられません。したがって、この値は合理的な範囲で小さいほど良いということになるのですが、REFRESH値は、一回の周期内で、すべてのゾーンに対する処理が収まるように決定する必要があります。参考までに以下に実例をあげておきます。

• 大手IT製品メーカー（ハードウェア/ソフトウェア）
  REFRESH: 1時間  RETRY: 20分　(3600/1200)
• 大手ISP　（企業向けが中心でユーザの独自ドメインが多い）
  REFRESH: 3時間 RETRY: 1時間 (10800/3600)
• 大手ISP （コンシュマー向け、携帯キャリヤー等）
  REFRESH: 30分 RETRY: 15分 (1800/900)

多数のユーザ企業向けにセカンダリーサーバを提供している企業向けISPでは、REFRESHは長めです。一方、ダイアルアップやそれに類似した接続の多いコンシュマー向けISP、携帯キャリヤーでは、短い値が設定されているのがわかります。プライベートネットワークで、クライアントPC向けにDHCP連携によるDDNSを行う場合、限られたIPアドレスを有効に利用するためREFRESHを短縮しますが、コンシュマー向けおよび携帯キャリヤーのREFRESH設定は類似したものとなっています。

一般的な企業では、以下の3600/1200の設定で、ほとんどの事例に対応できるはずです。

@	IN SOA  ns1.eis.co.jp. postmaster.eis.co.jp. (
        2009082401 ; serial
        3600       ; refresh (1 hour)
        1200       ; retry (20 min.)
        1209600    ; expire (2 weeks)
        900        ; minimum (15 min.)
 )

NOTIFYを使っている場合

今日現役ののDNSサーバは、そのほとんどがNOTIFY機能に対応しているはずです。NOTIFYを利用すれば、ゾーン情報が更新される毎にマスターサーバがスレーブサーバに能動的に通知しますので、スレーブサーバによるポーリングの周期の意味は低下します。ただし、NOTIFYを活かしてあってもポーリングは行われるのと、RETRYの値はプライマリーサーバに障害が発生している間は意味を持ちますので、NOTIFYを利用する場合も、前述の考え方でREFRESH/RETRYの値を決定しておけばよいです。

MINIMUMの二義性に注意

ゾーンファイルに記述する各リソースレコードのTTLは、$TTLでも随時指定することができますが、MININUMの値は、このパラメータの意味の二面性を考慮して決定すべきです。

DNSクエリーの参照結果をDNSクライアントはキャッシュすることにより名前解決の効率化を図ります。このときキャッシュされるものは、DNSクエリーの結果レコードが発見されたエントリー（ポジティブキャッシュ）のみではありません。ホスト名等、あるラベルについて、対応するレコードが存在しなかった場合、この「レコードが存在しない」という結果をキャッシュします（ネガティブキャッシュ）。

存在するレコードの有効期間については、MININUMと$TTLで指定した値が共に有効ですが、「存在しないレコード」については、MINIMUMで指定された値がTTLとしても適用されます。したがって、従来存在しなかったホスト名、IPアドレスを使用して新たにホストを追加した場合などには、そのホスト名あるいはIPアドレスが「存在しないという情報」がキャッシュされて、MINIMUMで指定された期間参照されていることを考慮しなければなりません。したがって、ゾーン情報の更新が、不特定多数のクライアントによるDNS参照にできるだけ早く反映されるためには、MINIMUMのは合理的な範囲で短命に設定することが好ましいということになります。前述のようにRFC1912では、1～5日間を標準的な設定としていますが、ホスト構成の変更が頻繁であるサイトでは、上記の例のように900（15分程度）に短縮しておくのが安心です。

SOAレコードの設定をスレーブサーバが鵜呑みにするとはかぎらない

 次回は、SOAに設定されたゾーン転送のタイミングパラメータの取り扱いを、スレーブサーバの立場から検討してみます。

次回につづく