ゾーンファイルは難しい？

named のゾーンファイルの書式は、 サーバー アプリケーション の設定ファイルの中でも難解な部類に入るでしょう。

いきなりですが、今回構築中のnamedの "obenri.com" に関する正引きゾーンファイル

"/var/named/obenri.com.zone"

と、自宅の サブネット に関する逆引きゾーンファイル

"/var/named/100.168.192.in-addr.arpa.zone"

の内容を順に示しましょう。

いかがでしょうか。 "/etc/named.conf" に負けず劣らず、まるで呪文のように思えるのではないでしょうか。

でも「何となく解るような気がする。」という感じもしませんか？。

namedのゾーンファイルは、その記述内容をわかりやすくすることよりも、後から内容を修正したり、他の ドメイン名 に転用したり、という作業が簡単に間違いなく行えるように書式が工夫されています。

例えば上の正引きゾーンファイルは、 "obenri.com" で使用するものでありながら、中の記述には "obenri.com" は使われていないことにお気づきでしょうか。

従ってこのゾーンファイルは、 ホスト名 さえ変更しなければ、そのまま他のドメイン名の正引きゾーンファイルとして使用できます。

一方、下の逆引きゾーンファイルは、 "192.168.100.0/24" のサブネットで使用するものでありながら、中にはサブネットの ネットワーク部 に関する "192.168.100" という記述が使われていません。

つまりこのゾーンファイルは、サブネットのネットワーク部が変更されてもそのまま使用できるわけです。

実はゾーンファイルは、こういった「柔軟な運用」を可能にするために、非常に多くの 省略記述 ができるようになっているのが特徴です。

では試しに、正引きのゾーンファイルを、省略しない形でわかりやすく記述してみましょう。

いかがでしょうか。下半分だけをみれば、 hostsファイル にそっくりに見えてきませんか。

関連セクション・ 固定IPでDNSサーバー構築

関連ページ・ 名前解決とネームサーバー

ブートファイルと異なるゾーンファイルの書式

ゾーンファイルは、それを読み込んで制御させるためのブートファイルと同じ アプリケーション の設定ファイルですが、ブートファイル "/etc/named.conf" とは書式が全く異なりますので、混同しないように注意してください。

例えば、 ";" は、ブートファイルでは命令文の終わりをあらわす記号ですが、ゾーンファイルでは 「行末までコメント文として無視する」 記号になります。

また、ブートファイルのコメント記号である "//" や、 "/*"〜"*/" は、ゾーンファイルではコメント記号として 使うことができません 。

ただしスペースとタブが、連続している場合に一つのスペースとみなされるのは同じで、設定内容を見やすくするためのインデントとして利用できます。

ゾーンファイル基本的な文法は次のとおりです。

１−１．SOA(管理)レコードの書式

ゾーンファイルの管理情報などを記述するレコードです。一般的な書式は以下のとおりです。

[ゾーン名] ．．．このゾーンファイルが管理する ドメイン名 、または サブネット の IPアドレス を記述します。

[DNSサーバー名] ．．．このゾーンファイルを管理する DNSサーバー 名を記述します。通常はこの named が動作している ホスト機 で、DNSサーバーとして利用したい FQDN を記述します。

[メールアドレス] ．．．このゾーンファイルの管理者(つまりあなた)の電子メールアドレスを記述します。ただし、ゾーンファイルの中では "@" は特別な意味を持つ記号として使われますので、代わりに "." を使用します(例： "tanaka.obenri.com." )。

実は [DNSサーバー名] と [メールアドレス] の二つのパラメータはnamedの動作には全く関係がなく、DNSサーバーの管理者が義務として記述するものです。

従って LAN で使用するDNSサーバーではあまり意味がありませんので適当でかまいませんが、 WAN で 「権威あるDNSサーバー」 として使用する場合には正しく記述する必要があります。

[Serial値] ．．．このDNSサーバーに対してスレーブDNSサーバーを設置するときに必要なパラメータのひとつです。

それではここで、[Serial値]の説明の前に、マスターDNSサーバーとスレーブDNSサーバー の関係と仕組みについて説明しましょう。

DNSサーバーのマスターとスレーブの働き

マスターDNSサーバーは特定のドメイン名、例えば "obenri.com" に由来するFQDNの名前解決を「権威をもって」担います。

ということは、もしもマスターDNSサーバーが「唯一の権威あるサーバー」だとすると、それが何らかトラブルを起こして動作しなくなれば、他のDNSサーバーに対して "obenri.com" に関する名前解決情報は一切発信されないことになってしまいます。

換言すれば、マスターDNSサーバーは、 ハードウェア のメンテナンスのために停止することも許されないことになります。

そこでDNSサーバーには、 バックアップとしてスレーブDNSサーバーを設置し 、マスターDNSサーバーが停止してもその代わりに名前解決情報を発信するような構成にするのが一般的となっていまです。

そして上の図のように、何らかの理由で外部からマスターDNSサーバーへの問い合わせが行えなくなっているときは、スレーブDNSサーバーが代わりに応答し、 "obenri.com" に由来する名前解決がインターネット空間で滞ることがないように配慮されているわけです。

実のところスレーブDNSサーバーには、

「マスターDNSサーバー "web1.obenri.com" の、 "obenri.com" の名前解決に関するゾーンファイルの内容を受け取り、マスターDNSサーバーと同じく権威を持った回答をしなさい。」

という設定のみしか行われません。

つまりスレーブDNSサーバーは、マスターDNSサーバーと同じくnamedで動作しますが、ゾーンファイルの記述は行われず、ブートファイル "/etc/name.conf" に「スレーブDNSサーバーとして動作せよ。」と記述されているに過ぎないわけです。

要するに、スレーブDNSサーバーは定期的にマスターDNSサーバーに問い合わせを行い、ゾーンファイルの内容が更新されていればそれを受け取り、自身の名前解決の内容を変更する、という単純動作を繰り返しているに過ぎないわけです。

説明が長くなりましたが、その問い合わせのタイミングをどうするか、あるいは更新のチェックをどうするか、といった指示は、オペレーターが直接スレーブDNSサーバーに行う訳ではなく、 マスターDNSサーバー上のゾーンファイル中のSOAレコードに記述されたパラメータによって決定される、 という仕組みになってます。

さて、 [Serial値] の説明に戻りますが、スレーブDNSサーバーは、マスターDNSサーバーのゾーンファイルの内容が変更されているかどうかを判断する場合、レコードの具体的な内容が変更になっているとか、ゾーンファイルの作成日が違っているとか、そういう情報は参考にしません。実はこの[Serial値]を参照します。

スレーブDNSサーバーは、前回のゾーン転送で得ているゾーンファイルの[Serial値]と、マスターDNSサーバーのゾーンファイルの[Serial値]を比較し、[Serial値]が大きくなっていれば「ゾーンファイルの内容が更新された」と判断して自分自身のゾーンファイルを更新します。

つまり、ゾーンファイルの内容を書き換えても、この[Serial値]を大きな数字に書き換えることを忘れてしまったら、ゾーン転送は行われないことになります。

この[Serial値]のつけ方には特にルールはありません。要は数値が整数であれば大小さえはっきりしていればOKです。しかし一般的には、

のように記述する習慣があります。

と、長々と説明してきましたが、事前説明のとおり、今回はスレーブDNSサーバーの設置は行いませんから、実はこの[Serial値]は何の意味もありません。 デフォルト のままで構いません。

[Refresh時間] ．．．このDNSサーバーに対してスレーブDNSサーバーを設置するときに必要なパラメータで、スレーブDNSサーバーがマスターDNSサーバーにゾーンファイルの更新の有無を問い合わせる時間間隔の設定値です。

デフォルトは "3H" つまり ３時間 です。

ただし今回はスレーブDNSサーバーの設置は行いませんから、この[Refresh時間]は何の意味もありません。デフォルトのままでOKです。

[Retry時間] ．．．このDNSサーバーに対してスレーブDNSサーバーを設置するときに必要なパラメータで、ゾーン転送がうまくいかなかった場合の、再問い合わせの時間間隔の設定値です。

デフォルトは "15M" つまり 15分 です。

ただし今回はスレーブDNSサーバーの設置は行いませんから、この[Retry時間]は何の意味もありません。デフォルトのままでOKです。

[Expire時間] ．．．このDNSサーバーに対してスレーブDNSサーバーを設置するときに必要なパラメータで、マスターDNSサーバーに問い合わせを繰り返しても応答が得られない状態が続いたとき、最初の問い合わせ失敗からここで設定した時間が経過すると、スレーブDNSサーバーはゾーンファイルの情報を破棄して名前解決を中止します。

デフォルトは "1W" つまり 一週間 です。

ただし今回はスレーブDNSサーバーの設置は行いませんから、この[Expire時間]は何の意味もありません。デフォルトのままでOKです。

[Minimum時間] ．．．namedでゾーンファイルの内容が変更され、名前解決ができなくなったケースが発生したとき、 「名前解決できません」という名前解決 をどのくらいの時間 DNSキャッシュ として保持するか、という時間の指定です。

デフォルトは "1D" つまり 一日 です。

例えばそれまで "http://www.obenri.com/" という URL で公開していたwebページを、 "http://info.obenri.com/" というURLに変更したような場合、変更を行ってからしばらくの間は、 クライアント からは元のURL "http://www.obenri.com/" へのリクエストが続くことが予想されます。

ということは、もしもネガティブキャッシュという仕組みが DNS に存在しなければ、DNSサーバーは「名前解決ができないことがわかりきっている名前解決」について、 ルートサーバー への問い合わせと「権威あるDNSサーバー」への問い合わせ、更にクライアントへの回答などの 無駄な通信と作業 を行わなければなりません。

こういった「無駄な問い合わせ」は、名前解決情報が失われた直後からしばらくの間は集中して発生しますから、その期間だけでも各々のDNSサーバーが単独で「名前解決できません」と回答してくれるように働いてくれれば、インターネット空間のパフォーマンスの低下を抑えることが可能となります。

つまりこの[Minimum時間]を大きくすれば、名前解決情報を削除した後のパフォーマンス低下は長く抑制されることになります。

しかしその一方で、一度削除した名前解決情報を復活させたい場合、削除してから最低[Minimum時間]を経過しなければ新しい名前解決情報を行き渡らせることができなくなります。

従って[Minimum時間]にあまり大きな値を設定すると逆に不都合が起こることがあります。

とはいえ、LAN内で使用するDNSサーバーは外部のDNSサーバーにDNSキャッシュを与えることはありませんから、この設定値が影響を与えるのはLAN内部のホスト機に関してだけということになります。

LAN内部のホスト機であれば、いざとなれば手動でDNSキャッシュを消去することも可能ですから、[Minimum時間]の大小による不具合は宅内で対処可能です。従ってデフォルト値を変更する意味は特にないといえるでしょう。

１−２．SOAレコードの見やすい書き方

ゾーンファイルの記述法の特徴は、他の サーバー アプリケーション で良く見られるような、

という形式ではなく、

というように、ただパラメータだけを並べた形式になっているため、各々のパラメータの意味が解りにくいという欠点があります。

もしもSOAレコードを何の工夫もせずに記述すると、次のようになります。

[ゾーン名]や[DNSサーバー名]、[メールアドレス]などは、その内容から大体の意味は解るとしても、"()"の中の時間のパラメータの順序はなかなか正確には覚えられないでしょう。

そこで、設定に影響を与えないスペースやタブとコメント記号を使って工夫された、以下のような記述法が一般的に使われているわけです。

この設定から、連続したスペースと ";" から行末までの文字を取り除いてみてください。上と全く同じ内容になることがお解かりと思います。

２．NS(名前解決)レコードの書式

特定の ドメイン名 に対して、 「権威を持って」 名前解決 を行わせる DNSサーバー を指定するレコードです。

[対象となるドメイン名またはサブネット] ．．．このゾーンファイルで設定の対象となるドメイン名、または サブネット の ネットワーク部 を記述します。

[TTL] ．．．このゾーンファイルの内容が、他のDNSサーバーや クライアント機 などで DNSキャッシュ として使用されるとき、その保持される時間を記述します。

通常は"一日"で過不足はありませんから、 "1D" 、記号を省略する場合は秒単位で "86400" と記述します。

[DNSサーバーのFQDN] ．．．[対象となるドメイン名またはサブネット]の名前解決を行うDNSサーバーの FQDN を記述します。

例えば、DNSキャッシュを一日に指定して "obenri.com" 由来のFQDNに関する名前解決を、 "web1.obenri.com" に行わせる場合には、

となります。ただしこのNSレコードではFQDNからIPアドレスへの名前解決の記述は行いませんから、dnsサーバーとするFQDNには別途必ずAレコードでIPアドレスを指定する必要があります。

またDNSサーバーは、他のドメイン名の名前解決も同時に行うことができます。 "obenri.com" というドメイン名を扱うからといって、 "*.obenri.com" というDNSサーバーを使用しなければならないというルールはありません。

例えば、

という具合にNSレコードを記述すれば、 "web1.obenri.com" は "uheuhe.com" の「権威あるDNSサーバー」として運用することができます。

もちろんサブネットに関しても複数を扱うことができます。

複数の権威あるDNSサーバー

ところで DNS には、

「一つのネットワーク空間においては、 ドメイン名 や サブネット は一つのまとまりとしてゾーンファイルに記述する。」

という決まりがあります。

例えば "obenri.com" について、 "www.obenri.com" と "info.obenri.com" の二種類の FQDN を利用したい場合、それぞれを別の IPアドレス に名前解決する場合でも、また、別々の サーバー機 上で運用する場合でも、ドメイン名が共通である以上は 「ただひとつのゾーンファイル」 にまとめて記述し、 「ただひとつの権威あるDNSサーバー 」 で名前解決に当たらなければなりません。

逆にいえば、一つのドメイン名に関する名前解決を複数のゾーンファイルにまたがって記述したり、複数の異なる DNSサーバー を「どちらも権威あるDNSサーバー」として運用することはできないということです。

という説明をすると、「おやっ？」と思われるかもしれません。

"obenri.com" は、 WAN 空間では既に で登録したDNSサーバーが「権威あるDNSサーバー」となっているはずです。

にもかかわらずここで同じドメイン名に対して "web1.obenri.com" を「権威あるDNSサーバー」として設置するのはルール違反ではないのでしょうか。

ここで思い出して欲しいのは、現在構築中のDNSサーバーは、あくまで LAN の中で限定して使われるものだということと、そのLANは NAT + IPマスカレード でWAN空間からは基本的に遮断されているということです。

まず、LAN内部で運用するDNSサーバーは、意図的に ポートフォワーディング でWAN空間からの接続を有効にしないかぎり、外部のネットワークからは参照されることはありません。

一方、LAN内部のDNSサーバー "web1.obenri.com" からは、WAN空間のDNSサーバーへの問い合わせを普通に行うことになります。

しかし "web1.obenri.com" は、 「自分自身が権威をもって 名前解決 を行うドメイン名 "obenri.com" 」についてだけはすべて自分自身で処理し、外部への問い合わせを行いません。

というわけですから、現在構築中の通信システムは、巧妙に二つの権威あるDNSサーバーを共存せさせているといえます。

３．MX(メールサーバー情報)レコードの書式

特定の ドメイン名 に対して、 「権威を持って」 動作する メールサーバー を指定するレコードです。

[対象となるドメイン名] ．．．このゾーンファイルで設定の対象となるドメイン名を記述します。

[TTL] ．．．このゾーンファイルの内容が、他のDNSサーバーや クライアント機 などで DNSキャッシュ として使用されるとき、その保持される時間を記述します。

通常は"一日"で過不足はありませんから、 "1D" 、記号を省略する場合は秒単位で "86400" と記述します。

[Priority値] ．．．利用するメールサーバーの優先順位を決定するパラメータです。

メールサーバーは、 webサーバー や FTPサーバー などと異なり、その名前のとおり郵便局と同じ役目を担いますから、簡単にストップしてしまう訳にはいきません。

従ってDNSサーバーと同様に、メインのメールサーバーがダウンしたときのためにバックアップサーバーを動作させておくことがあります。

バックアップメールサーバーは、メインのメールサーバーがダウンしたときに送受信を代行し、メインのメールサーバーが復帰したらまたバックアップに戻る、という賢い動作をします。

この[Priority値]は、数字が小さいほど優先度が高いメールサーバーであることを表します。例えば、

と記述した場合、 "mail.obenri.com" をメインのメールサーバー、 "mail2.obenri.com" をバックアップのメールサーバーとして使用できるようになります。

[Priority値]は0〜65535の範囲ならばどうでも構いませんが、メインのメールサーバーには "10" が使われ、以後 "20" 、 "30" とするような習慣があります。

メールサーバーを一つだけしか運用しない場合でもこの[Priority値]は省略できませんから、そういう場合は、

としておきます。

[メールサーバーのFQDN] ．．．利用するメールサーバーのFQDNを指定します。

ただしこのMXレコードではFQDNからIPアドレスへの名前解決の記述は行いませんから、メールサーバーとするFQDNには別途必ずAレコードでIPアドレスを指定する必要があります。

４．A(アドレス情報)レコードの書式

FQDN に対する IPアドレス を指定するレコードです。つまり「正引き」のためのレコードです。

[対象となるFQDN] ．．．設定の対象となるFQDNを記述します。

[TTL] ．．．このゾーンファイルの内容が、他のDNSサーバーや クライアント機 などで DNSキャッシュ として使用されるとき、その保持される時間を記述します。

通常は"一日"で過不足はありませんから、 "1D" 、記号を省略する場合は秒単位で "86400" と記述します。

[IPアドレス] ．．．[設定の対象となるFQDN]に対応させるIPアドレスを記述します。

５．CNAME(別名)レコードの書式

FQDN に対して「別名」としてのFQDNを指定するレコードです。

これは、たくさんのFQDNを一つの IPアドレス に 名前解決 するように設定したいようなとき、後々の手間を省くためによく用いられる方法です。

[別名として設定するFQDN] ．．．[参照元のFQDN]に対し、その別名として設定するFQDNを記述します。

[TTL] ．．．このゾーンファイルの内容が、他の DNSサーバー や クライアント機 などで DNSキャッシュ として使用されるとき、その保持される時間を記述します。

通常は"一日"で過不足はありませんから、 "1D" 、記号を省略する場合は秒単位で "86400" と記述します。

[参照元のFQDN] ．．．[別名として設定するFQDN]に対応させるFQDNを記述します。

このCNAMEレコードは、例えば、

のように使用します。このように記述すると、 "web1.obenri.com" を除くその他のFQDNは

「"web1.obenri.com"の別名。」

と解釈されますので、結果的に同じIPアドレスを指し示すことになります。つまり、下の記述と同じ意味になるわけです。

例えばこれらのFQDNが指し示すIPアドレスを全て変更しなければならないとき、上のCNAMEを使った記述では一つのIPアドレスの書き換えで済むのに対し、下のAレコードだけの記述ではすべてのIPアドレスを書き換えなければならなくなります( 赤 で示す部分です)。

ただ、このCANMEレコードは、非常に多くの名前解決を担い、なおかつそれらを頻繁に書き換えなければならない ISP のDNSサーバーなどで「快適性より利便性を優先して」用いられるものです。

実をいうと、例えばAレコード

の場合、 "ftp.obenri.com" はすんなりと "192.168.100.11" に名前解決されますが、CNAMEレコード

の場合は、一度

「"ftp.obenri.com"は"web1.obenri.com"の別名である」

いう処理の後にIPアドレスへの名前解決を行うことになりますから、namedにとっては余計な仕事が増えることになります。

実際の処理の負荷で言えば取るに足りない差かもしれませんが、ゾーンファイルが頻繁に書き換えられることのないような小規模なDNSサーバーでは、CNAMEの利用はあまり意味がないと思って構わないでしょう。

６．PTR(逆引き)レコードの書式

IPアドレス に対する FQDN を指定するレコード、いわゆる「逆引き」のレコードです。

[対象となるIPアドレス] ．．．設定の対象となるIPアドレスを記述します。ただし、一般的なIPアドレスの表記法ではなく、 オクテット を反対向きに並べて、最後に ".in-addr.arpa." という文字を付けて表記する必要があります。例えば、

となります。

[TTL] ．．．このゾーンファイルの内容が、他の DNSサーバー や クライアント機 などで DNSキャッシュ として使用されるとき、その保持される時間を記述します。

通常は"一日"で過不足はありませんから、 "1D" 、記号を省略する場合は秒単位で "86400" と記述します。

[FQDN] ．．．[対象となるIPアドレス]に対応させるFQDNを記述します。

named を運用する場合、Aレコードで正引きを設定したIPアドレスに対しては、原則としてPTRレコードを設定します。

また、Aレコードの場合は、複数のFQDNを一つのIPアドレスに割り当てるケースが一般的ですが、PTRレコードの場合は普通、一つのIPアドレスについて一つのFQDNを割り当てます。

逆引き設定の必要性について

インターネットの一般的な利用だけを見るならば、FQDN→IPアドレスで「所在地を特定する」という「正引き」の名前解決が大部分です。

その逆のIPアドレス→FQDNという「所在地から名前を特定する」という「逆引き」は、卑近な例でいえば電話番号から電話の持ち主を特定するようなもので、特別な場合を除いて実用上はあまり重要ではない行為といえるでしょう。

ただ、ここでいう「実用上重要ではない」という意味は、あくまで クライアント 用途として であって、 サーバー 運用上は重要な意味を持ちます。

例えば、 セキュリティ を重視するサーバー アプリケーション には、「FQDNに逆引きができないIPアドレスからのアクセスを拒否する。」といった設定が施されているケースがめずらしくないため、逆引きの設定を怠ると思ったような運用ができないことがあります。

またサーバーアプリケーションは一部の例外を除くと、外部からの接続に対しては必ずアクセス ログ を記録します。

もちろん、 TCP/IP では パケット に「発信元のIPアドレス情報」が付加されていますから、IPアドレスを元にした統計であれば、サーバーアプリケーションにとっては雑作もないことです。

しかし実のところ、数字の羅列であるIPアドレスだけの統計から得られるアクセス履歴は、情報としてあまり有用ではありません。そこで、サーバーはそれらのIPアドレスに対して逆引きを行い、アクセス元のFQDNを特定します。

ドメイン名での統計が得られれば、アクセスの中心が何処の国なのか、会社なのか学校関係なのか、といった「意味のある統計情報」となるわけです。

PTRレコードは、その効果が解りにくいのでつい「ないがしろ」にされがちですが、きちんと記述するよう心がけましょう。

関連セクション・ 固定IPでDNSサーバー構築

関連ページ・ 名前解決とネームサーバー