BIND記述方法の詳細（改BIND9対応）！

いがいとBINDは奥が深い。小生も未だに設定にとまどうことがある。技術の部屋でも何回かBINDの設定は取り上げてきた。しかし、今回は、もう少し詳細に説明を行ってみようと思う。あくまでも、小生なりの説明であるが（笑）。

[設定条件：]
名前DNSサーバで固定IP１個、逆引きセカンダリDNSサービス有。

---

１．初めは/etc/named.confの記述法

「；」は、文末記号、コメントは「＃」を行に付ける。
コメントには、C言語、C++のように、「/*・・・・・*/」とか「//」も使える。

① optionsステートメント
namedの動作全体に適用されるオプションを指定するブロックである。
ゾーンファイルを格納するディレクトリ等を指定することが出来る。

② zoneステートメント
ネットワーク毎のホスト、IPアドレスを定義するブロックである。

２） ゾーン名
ネットワーク（ゾーン）の名称である。
通常、正引きゾーンはドメイン名を、逆引きゾーンはネットワークの逆引きドメイン名を指定する。
逆引きドメインは、ネットワークアドレス指定部分の下位から逆に指定して、in.addr.arpaと言うトップレベルドメインを追加したもの。1.168.192.in.addr.arpaみたいになる。

---

コラム １：
■　ゾーンの定義の説明！
ゾーンはドメインより、さらに細かくネットワークを分割したものであるが、ドメインとほぼ同じものとして考えて差し支えない。１つのネットワークに対して、正引きゾーン、逆引きゾーンの２つが含まれる。それぞれのゾーンは、”ゾーン情報” と言うホスト名やアドレス情報で管理されている。サブドメインが構成されている場合は、ゾーン情報はドメインのものとサブドメインのものがそれぞれ別のも のになる。ゾーンとドメインの違いは、DNSサーバの権威の範囲の違いである。例えば、hogehoge.jpドメインはjpドメインに含まれるが、jp ゾーンを管理しているDNSサーバはhogehoge.jpゾーンに対して権威を持っていない。したがって、hogehoge.jpゾーンはjpゾーンに 含まれない。だが、hogehoge.jpドメインとsub.hogehoge.jpサブドメインのゾーン情報を一台のDNSサーバで管理している場合、 sub.hogehoge.jpゾーンはhogehoge.jpゾーンに含まれるのだ。

---

コラム ２：
■ Non-authoritative answer ってどういう意味！？

C:\>nslookup www.kozupon.com
Server: ns.hogehoge.jp
Address: 192.168.0.4

Non-authoritative answer: ← ※
Name: sub2.kozupon.com
Address: 203.141.144.180
Aliases: www.kozupon.com

neslookupコマンドを叩いて、例えば上記のような正引き情報を得ようとすると、※印の「 Non-authoritative answer: 」というレスポンスが出力されるに気が付いた人はいるだろう。
authoritativeの意味は、”信頼できる”という意味であり、つまり”信頼できない答え”という訳になる。「じゃあ、Aboutだから間違ってるのかよ！？」
いや、そう言うことではない。この意味を知るには、DNSの問い合わせの構造を理解しなくてはならない。では、DNSの名前解決の一連のプロセスを以下に示す。

● 同ローカルセグメントにAクライアントとDNSが動いてるBサーバが有るとする。

①　「http://www.kozupon.com/」と言うURLの問い合わせが AクライアントというPCから出力された。

②　問い合わせパケットは、Aクライアントのresolv.confのnameserverセクションのIPアドレスを見て同ドメイン内の Bサーバ（DNSサーバ）へ問い合わせに行く。このBサーバをrecursiveサーバ：回帰的サーバという。つまり、このBサーバはAクライアントに対して回帰的なサービスを提供してる、という言い方をする。

③　次に、Bサーバはwww.kozupon.comと言うauthoritative サーバ（信頼できるなサーバ）を見つけるべく、まずrootサーバに非回帰的に問い合わせに行く。rootサーバは問い合わせに答え、問い合わせに対する NSレコードの情報によってcomゾーンのDNSサーバの情報をBサーバが得る。

④　次に、BサーバはcomゾーンのDNSサーバに対してkozupon.comゾーンのDNSサーバの情報を得る。

⑤　最後に、Bサーバはkozupon.comゾーンのDNSサーバ（sub2.kozupon.com）に対して問い合わせを行い、最終目的のwww.kozupon.comサーバのIPアドレスを得る。

以上がDNSの名前解決のプロセスだが、ここで気が付いたことがあると思う。それは、
a. ローカル領域でのAクライアントとBサーバのやりとり
b.グローバル領域でのBサーバとrootサーバ、comゾーンサーバのやりとり
aは、回帰的サービス（recursiveサービス）という。あくまでもローカルBサーバとローカルクライアントのやりとりとなる。したがって、ブラウザが信頼できる情報の在処は自分で設定してるDNSサーバつまり、Unixではresolv.conf 、WindowsではレジストリにかかれているDNSサーバである。
さらに、Bサーバへブラウザから毎回問い合わせが発生してもBサーバ自身は問い合わせデータ（recursiveデータ） は保持していない。
bは、信頼できるサービス（authoritativeサービス）と いう。あくまでも、グローバルでのBサーバとrootサーバやcomゾーンサーバその他のやりとりとなる。信頼できる問い合わせ情報は、DNSのNSレ コードのDNSサーバのIPアドレス及びホスト名である。つまり、インターネット上で行き来している問い合わせ情報の殆どはDNSサーバのNSレコードな のである。
さらに、authoritativeサービスは問い合わせデータを保持しているため、事実上毎回問い合わせ手順を踏んでるわけではない。
DNS情報の問い合わせの効率化のためにキャッシュしてるのである。
これでもう解ったと思うが、「 Non-authoritative answer: 」と言うのは”authoritativeサービスではない、キャッシュから引っ張ってきてる情報だよ！”って教えてくれてるのである。しかし、これは決してあいまいなデータと言うことではなくキャッシュされたデータだと言うことなのである。反対に、「 Non-authoritative answer: 」が表示されないときは、”authoritativeサービスのデータだよ！”と言うことである。「 Non-authoritative answer: 」が表示されないときの殆どは問い合わせたホストが初めてauthoritativeサーバへ問い合わせされた時だろう。

---

３） type
ゾーンのタイプを定義する。
master、slave、hintが指定できる。masterが指定された場合、このnamedがオリジナルのデータを管理している。つまり、マスタ サーバ（プライマリサーバ）で有ることを示す。slaveが指定された場合、スレーブサーバ（セカンダリサーバ）となり、マスタサーバからゾーン転送した データを保持して動作することを示す。hintが指定された場合、マスタ、スレーブサーバでもなく、単にキャシュとして動作することを示す。

４） ファイル名
そのゾーンの名前解決に使用するゾ−ンファイル名。

５） named.confファイルの記述例
以下は、小生の現在のDNSサーバのnamed.confの内容である。
BIND9からviewステートメントが追加され、ローカル／グローバルネットワークの記述が容易になった。したがって、ここでの例ではviewステートメントでローカルネットとグローバルネットの設定を分けている。

①　aclはアクセスコントロールリストの略で、一言でいうとラベル定義。ここでは、localnetというラベルを作りネットワークアドレスとローカルホストを定義づけている。

② loggingで定義している、lame-serversとはネットの世界でDNS情報を発信しているDNSサーバの設定ミスにより、他の人のDNSサーバにlame-serversエラーログを発信することこう言う。したがって、category lame-servers { null; }; この記述は、lame-serversのログを消去するパラメータだ。

③ auth-nxdomainとは、これが「yes」だとBIND8デフォルト互換、「no」だとRFC1035準拠と言う意味。

④ クエリーとは問い合わせの意味。allow-queryとは、クエリーを受けるホストを制限するパラメータ。

⑤ ゾーン制限をするためoptionステートメント内でサブコマンド記述する。ここでは、203.141.128.33のセカンダリネームサーバのみにゾー ン転送を指定している。複数指定する場合は、IPアドレスの最後に”;”で区切り複数指定する。zoneステートメント内でも、 個々のzoneに対して個別に指定できる。結構、ゾーン転送を制限するとゾーンのレコード情報が漏洩しないのでセキュリティ対策にも大いに役立つので、便 利なコマンドである。是非必要に応じて書き添えていただきたい。

⑥ ②のlogの保存期間

⑦ viewステートメントは、分離されたゾーンの管理を個々に行える。例えば、記述例のようにLocalとGlobalのようなゾーンの定義の仕方である。ローカルとグローバルのおのおので名前解決が必要な場合には優れた機能である。

⑧ match-clientとは、viewステートメントで定義したゾーン情報を制限する。たとえば、記述例のように match-client { localnet; }; と書かれている場合は、localnetで定義したグループからしかゾーン情報が参照できない。

⑨ recursion とは、前述した再帰的やりとりをするかしないかである。この再帰的やりとりは、DNSサーバの各レベルを検索してサーバからサーバへ移動して得られた情報 を全てキャッシングする。だから、セキュリティ的にはローカル側だけに制限してグローバルゾーンでの再帰はなしにするべきと考える。

⑩ zone”.” ゾーンは、インターネット全体を示す。各国のトップレベルドメインを管理するDNSサーバ（ルートサーバ）に関する情報を定義しており、type hintを指定してキャシュとして動作させている。

■ ローカルネットとグローバルネットの各zone “kozupon.com”kozupon.comドメインのローカルネットもしくはグローバルネット正引きゾーンを設定している。type masterでプライマリとして、このサーバがオリジナルのゾーンファイルを持つように設定している。

■ zone “0.0.127.in-addr.arpa”localhostに対する逆引きゾーンを設定している。

■ zone “255.168.192.in-addr.arpa”kozupon.comドメインのローカルネット逆引きゾーンを設定している。

■ zone “180.144.141.203.in-addr.arpa”kozupon.comドメインのグローバルネット逆引きゾーンを設定している。

⑪ notify yes（番外） zoneステートメント内でこのサブコマンドを記述する。即刻、ゾーンのマスターサーバがそのゾーン内の変更をスレーブサーバに通知する。したがって、更 新手順が始まるまでの時間も待つ必要が無く、更新内容は直ぐにスレーブサーバに広がる。

その他のステートメントやオプションについては、 ここ で書いているので参考にして欲しい。

---

２．各ゾーンファイルの詳細

１） ゾーンファイルの記述方法

[<名前>][<TTL>][<クラス>]<レコード種別><パラメータ>・・・

[　]は省略可能なパラメータ。”;”はコメントを、( )は継続行を表す。
”名前”は、検索対象になるデータの名前である。”@”を指定すると、ゾーンファイルの先頭部分で指定された$ORIGIN値が対象となる。省略すると、その直前のレコードと同じものが指定された事になる。名前はFQDNで指定された場合、そのまま適用されるが、違う場合、最後に”．”が無い場合、名前の後にそのゾーン名が付加される。
”クラス”は、そのデータのクラスで、一般的にはInternetを表すINを使う”レコード種別”は、そのレコードがどのような種類であるかを表し、”パラメータ”はレコードの種類に応じた値を記述する。namedは、名前解決のリクエストがあると、パラメータを返す。と言う形で動作してる。

２） ローカルネット正引きゾーン
以降のゾーンファイルの例は、小生の環境がISPから固定IP一個を支給され作ったBINDの設定である。

この場合、NSレコードには、プライマリDNSサーバ名のみで、セカンダリは書く必要はない。
IPアドレスは、127.0.0.1、ホスト名がFQDNでlocalhostと言うホストについて逆引き設定をしている。
PTRレコードは、正引きゾーンファイルで設定したlocalhostに関して、逆引きの情報を設定している。

４） ローカルネット逆引きゾーン

$TTLはBIND8.2.1以降、必ず指定をしなければならなくなった。TTLの設定を$TTLとしてソースファイルのSOAレコードの前に記述する。この場合、SOAレコードで定義したTTL値よりもゾーンファイルの先頭で定義より、この先頭で定義した$TTLの方が優先される。ここでは、86400秒(１日)を指定している。

---

コラム ３：
■ $TTLが生まれた理由！
俺が理解してることを書く。BINDの古いバージョンには、否定キャシュ機能は無かった（と言うより行わなかったの方が正解かな？）。
否定キャシュとは、”参照した名前が見つからない時に、その名前が見つからないと言う情報がSOAレコードのminimumTTL（defaultTTL）の時間だけキャシュ内に保存される” という定義。これが現状。つまり、minimumTTLは古いBINDのバージョンではキャシュの保存期間として使われていたが、否定キャシュ機能が増え たことにより、$TTLがキャシュの保存期間になり、SOAレコードのminimumTTLが否定キャシュ時間になったと言うこと。俺的にはこのように解 釈している。

---

SOAレコードは、名前を”@”を使って、省略しマスタサーバをmichi.kozupon.comに、管理者のメールアドレスをroot@kozupon.comに設定している。
また、NSレコードでは、kozupon.comを管理するDNSサーバmichi.kozupon.com（このサーバつまりnamedが動いてるサーバ）、TEGTAN1.INTERLINK.OR.JP（セカンダリサーバISP側）を指定している。
MXレコードでは、kozupon.comゾーンのメールサーバにmail.kozupon.comを指定している。優先度は10に設定している。
Aレコードでは、サーバの登録をしている。まず、ローカルホスト、このサーバ、他のサーバと言う順に登録している。ここで、小生のホストは同じグローバルIPで羅列しているが、NATでアドレス変換をしたとき、全て一つのIPアドレスで変換されるからである。 ホスト名は、おのおの別のサーバであり、バックアップサーバも含んでいる。全てが稼働しているわけではないが、いつでも入れ替えられるように眠っているサーバもAレコードで定義しているのである。
尚、Aレコードで定義するIPアドレスは他のサーバと重複してもかまわない（但し、当然ながら正引きの場合のみ）。さらに、CNAMEレコードでwww、smtp、その他を別名で定義してる。

６） グローバルネット 逆引きゾーン

逆引きゾーンファイルには、基本的には正引きゾーンファイルで設定したホストに対応する PTRレコードを記述する。しかし、小生の環境では冒頭に述べたように、IPアドレスが１つしかない。したがって、ネットワーク 180.144.141.203.in-addr.arpaは、ホストが１つなので逆引き設定ホストも１つの名前しか定義できない。この場合は、 INTERNICに登録したホスト名を記載すべきである。ここでは、sub2.kozupon.comを設定している。
通常は、逆引きを使うことがほとんど無いため逆引き効果の意味が問われるが。しかし、最近のインターネット上のメールサーバはセキュリティのためのメール設定が随所で行われている。メールサーバのセキュリティ設定の一つに”逆引きを行えないホストをはじく！”という設定がある。つまり、逆引きを行えないホストは怪しいと判断するわけである。これについての議論は有るだろうが、実際にこのような設定が各種MTAで出来ることを覚えておいて欲しい。

７） BINDの起動確認

sub2:/etc/bind# tail /var/log/daemon.log

May 11 18:14:54 sub2 ntpd[1182]: synchronized to 203.255.112.4, stratum 3
May 11 18:31:59 sub2 ntpd[1182]: synchronized to 133.100.9.2, stratum 1
May 13 12:09:29 sub2 named[15039]: shutting down: flushing changes
May 13 12:09:29 sub2 named[15039]: stopping command channel on 127.0.0.1#953
May 13 12:09:29 sub2 named[15039]: no longer listening on 192.168.255.103#53
May 13 12:09:29 sub2 named[15039]: no longer listening on 127.0.0.1#53
May 13 12:09:29 sub2 named[15039]: exiting
May 13 12:09:32 sub2 named[8015]: starting BIND 9.2.4 -c /etc/bind/named.conf -u bind
May 13 12:09:32 sub2 named[8015]: using 1 CPU
May 13 12:09:32 sub2 named[8015]: loading configuration from '/etc/bind/named.conf'
May 13 12:09:32 sub2 named[8015]: no IPv6 interfaces found
May 13 12:09:32 sub2 named[8015]: listening on IPv4 interface eth0, 192.168.255.103#53
May 13 12:09:32 sub2 named[8015]: listening on IPv4 interface lo, 127.0.0.1#53
May 13 12:09:32 sub2 named[8015]: command channel listening on 127.0.0.1#953
May 13 12:09:32 sub2 named[8015]: zone 0.0.127.in-addr.arpa/IN: loaded serial 2003092101
May 13 12:09:32 sub2 named[8015]: zone 255.168.192.in-addr.arpa/IN: loaded serial 2006012302
May 13 12:09:32 sub2 named[8015]: zone kozupon.com/IN: loaded serial 2006012302
May 13 12:09:32 sub2 named[8015]: zone 180.144.141.203.in-addr.arpa/IN: loaded serial 200502020
1
May 13 12:09:32 sub2 named[8015]: zone kozupon.com/IN: loaded serial 2006051301
May 13 12:09:32 sub2 named[8015]: running
May 13 12:09:32 sub2 named[8015]: zone kozupon.com/IN: sending notifies (serial 2006051301)
May 13 12:09:32 sub2 named[8015]: zone 180.144.141.203.in-addr.arpa/IN: sending notifies (seria
l 2005020201)
May 13 12:09:32 sub2 named[8015]: client 203.141.128.33#53980: transfer of 'kozupon.com/IN': AX
FR-style IXFR started
May 13 12:09:33 sub2 named[8015]: client 219.111.9.211#49485: transfer of 'kozupon.com/IN': AXF
R-style IXFR started

このような、起動ログが確認できればOK！

---

コラム ４：
■ ローカル内のDNSサーバがグローバル側の名前解決を行いたいときの設定！
BINDには、ローカル側でLAN内の名前解決用の設定のみで、グローバルの名前解決をしたいときに名前解決をして貰うグローバルDNSサーバを指定できる。それは、以下のようにforward only; とforwardersを使って行う。

forward first と forward only の二つのモードがあって、これを指定しないでforwarders指定のみだとデフォルトが forward first になっている。 forward first は、最初にクエリーをフォワードしてから、それが失敗すると自分自身で名前解決を始める。つまり、プロバイダのDNSサーバから一定時間に回答が得られない場合には自分でルートサーバに問い合わせに行く、名前解決に自分でトライする訳だ。したがって、

みたいにお決まりのルートサーバを指定してると、以下のようなクエリーの警告メッセージが大量にログ出力されることがある。これは、 forwarders で指定しているプロバイダのDNSサーバがリストでルートサーバを指定しているのにもかかわらず自分自身もルートサーバをリストで指定しているので二重にNOTIFYメッセージは送らない旨を警告してる。

変わって、 forward only は forwarders で指定するサーバーに問い合わせして一定時間に回答を得られなくても自分自身ではで名前解決することはない、つまり常にクエリーをフォワードする。したがって、zone”.”が指定されていてもルートサーバーには問い合わせしない。
forwarders ：
自分自身で解決できない場合にここで指定したサーバーに問い合わせる。

以上