* DNS 逆引きの仕組み [#a365ee54]
BIND の設定を始める前に，逆引きの仕組みについても触れておこう.
実は，利用者のよくある直感と異なり，DNS の逆引き(IP アドレスから他の情報を知る)に特別な仕組みは用意されていない.
IP アドレスも FQDN のように階層構造をしていることを利用して，
「IP アドレスもホスト名の一種であるとみなして DNS の仕組みに紛れ込ませる」
ことで逆引きを実現している.
具体的には，"in-addr.arpa." という特別なドメイン((つまり，逆引き専用のドメイン))の下に，IP アドレスを逆向きにして((IP アドレスは「左側がより大きなグループで，右側ほど細かい指定」で，ホスト名はこの逆であるため))ホスト名とみなして DNS で取り扱う.
例えば，192.168.125.107 という IP アドレスは，107.125.168.192.in-addr.arpa. というホスト名で DNS で登録，検索されることになる.
逆引き設定ではこの知識が必要なので覚えておこう.
*** 実習 [#c4b17fe1]
dig コマンドなどで，上の仕組みを実感してみよう.
具体的には，自分のマシンの IP アドレス 192.168.125.??? にたいして
host -t PTR ???.125.168.192.in-addr.arpa.
dig -t PTR ???.125.168.192.in-addr.arpa.
nslookup -q=PTR ???.125.168.192.in-addr.arpa.
として，自分のマシン名がきちんと返答されているのを確認してみよう((問い合わせタイプをレコード "PTR" にしている. これは "ANY" にしてもよい. )).
また，
nslookup -q=ANY 125.168.192.in-addr.arpa.
などとしてみた場合にどうした返事が返ってくるか見てみよ.
* DNS 問い合わせクライアントとしての設定 [#f88ddd4d]
これまた BINDの設定の前に，DNS の問い合わせの設定は FreeBSD でどのようにされているか書いておこう.
FreeBSD では DNS 問い合わせを行う時の設定は基本的に /etc/resolv.conf というファイルに書き込むことになっている.
詳細は man resolv.conf として読んでもらうことにして，最低限の説明を書いておこう.
| オプション | 例(どれも1行で書かれる) | 説明 |h
| nameserver | nameserver 192.168.125.14 | DNS の(再帰的)問い合わせ先. もちろん受け付けてくれる相手でないといけない. nameserver オプションは 3つまで指定でき，上から順に試される. |
| domain | domain cl.math.sci.osaka-u.ac.jp | ローカルドメイン名. これを書いておけば，ローカルドメインに所属するホストを検索する際に最初の . 以降を省略できる. search とは排他的. |
| search | search math.sci.osaka-u.ac.jp sci.osaka-u.ac.jp | 検索の際，補完するために使われるドメインのリスト. 空白で区切る. domain とは排他的. |
*** 実習 [#c6de2947]
/etc/resolv.conf の search オプションを設定して，活用してみよう.
具体的には，
> search cl.math.sci.osaka-u.ac.jp math.sci.osaka-u.ac.jp sci.osaka-u.ac.jp
という行(これも1行で書くこと)を resolv.conf に加えた後，
host www
や
dig +search -t ANY mail
などとしてみよう((dig コマンドは，デフォルトでは search オプションを無視することがあるので, +search としておく)).
* DNS サーバの多重化 [#u5610a39]
次に，DNS サーバの多重化についても述べておこう.
DNS サーバはインターネットで非常に重要な役割を果たすものであるので，あるドメイン情報を管理しているサーバが 1台しかない，という状態はあまりにも心細く，避けるべきである.
そこで，DNS サーバは基本的に2箇所以上に多重化することになっている((いままで dig 等で DNS 情報を見たときに，どのドメインの担当サーバも複数あったことを思い出そう)).
そして，データの整合性や，更新については仕組みがきちんと考えられている.
これは，1つのゾーン(1つの DNS 情報の責任範囲と思えばよい)について，そのオリジナル情報をもつサーバ ''マスターサーバ'' を1台と，そのコピー情報をもつサーバ ''スレーブサーバ'' を 1台以上用意すること，として実現される.
そうして，オリジナル情報がマスターサーバからスレーブサーバに定期的ないしは更新時にすぐコピーされる((これをゾーン転送という.ゾーン転送も DNS サーバの仕事なので，人間が手を下す必要は特にない.))ことで，これら複数のサーバがほぼ同じ情報を持つ仕組みになっている.
なお，DNS 問い合わせを行うクライアントから見るとマスターサーバかスレーブサーバかの区別はなく，単に「早く答えた奴」などから答えを得るようになっている.
* DNS サーバの親子関係 [#y53481a5]
DNS が階層的であり，その情報を管理する DNS サーバも階層的になっていることは先の授業の dig +trace の例で理解できているだろう.
さて，ではその階層，親子関係(親がより大きなドメインを，子はその中のサブドメインを管理しているサーバということになる)は実際にどのように管理されてだろうか.
これはちょっと考えれば分かることだが，「親サーバが，子サーバがサブドメインを管理していることを知っていればよい」((子は親を直接知る必要はない. なんなら一番上の祖先(ルートサーバ13台)からたどれば済むのだから.)).
具体的には，親サーバのそのゾーン(ドメイン)情報の中に，子サーバが管理するゾーン(ドメイン)とその子サーバの対応がかかれていればよい.
分かり易いように具体例で書こう.
例えば，ある親サーバが aaa.com ドメインを管理していて，子サーバ ns.sub.aaa.com(192.168.125.105) がサブドメイン sub.aaa.com を管理するとしよう.
この時は，親サーバの aaa.com ゾーン情報内に
sub.aaa.com. IN NS ns.sub.aaa.com.
ns.sub.aaa.com. IN A 192.168.125.105
と書くことになる.
当たり前だが，二行目の情報がここに書いてあるか他のDNSから引けないと，ns.sub.aaa.com. にアクセスできないので意味がない.
さて，この話を逆に言えば，
「親サーバが，子サーバがサブドメインを管理していることを知らない」= 「親サーバで上のような設定をしていない」
状況にすれば，そのサブドメインの情報は「子サーバに直接問い合わせる人たちしか知らない」ので，あくまでローカルにサブドメインを使うことも可能である((自宅でのみ通用するサブドメインを管理するなどが考えられる状況かな. もちろん，この場合はこのサブドメイン情報を使って外からアクセスすることはできない.))．
* BIND の基本設定 [#zb47f29a]
BIND の仕事はゾーン設定やリゾルバ(DNS問い合わせに答えること)などがあるわけだが，まずは動かすために最低限の設定を行ってみよう.
これだけでも充分意味がある.
** named.conf の設定 [#c93cffda]
/etc/namedb (本当は /var/named/etc/namedb )以下に，BIND 自身の設定ファイルである named.conf がある.
これを書き換えれば，BIND の大まかな動作が変えられる.
ちなみに，named.conf の文法チェック専用に named-checkconf というコマンドがあるので覚えておこう.
さて，コメントを無視すると，デフォルトではこのファイルには次のような項目しかないだろう.
options {
directory "/etc/namedb";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
listen-on { 127.0.0.1; };
};
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "master/localhost.rev";
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA" {
type master;
file "master/localhost-v6.rev";
};
これをみるとおおよそ分かるように，このファイルの設定形式は単純で，options か zone ぐらいしか設定項目はなさそうだ.
実際には他に acl(アクセス制限をかける), include(ファイルを別に読み込む), server(他の DNS サーバとの接続設定)などが設定できるが, まあ今は気にしなくてよいだろう.
*** named.conf の options [#we15a28e]
named.conf を編集する前にまずはバックアップをとろう((こういう癖をつけることが大切だ. 誰にとって? それはもちろん君にとってだ. )).
さて，options では BIND 自身の動作を決めるオプションを設定する．
デフォルトで書かれているものはほぼそのまま使えるものとして，ほとんどいじらないでもよい.
ただし，これから皆のサーバは各々他からの問い合わせにも答える DNS サーバとして設定するので，他からの問い合わせを無視しては意味がない.
そこで，
// listen-on { 127.0.0.1; };
と, listen-on 行はコメントアウトしておこう.
他に options で設定によく使いそうなものとしては以下のものがある.
| ステートメント | 設定例 | 説明等 |h
| forward | forward only; もしくは forward first; | only の場合，自分で持っていない情報は全て人任せ(^-^) first の場合は，まず人に任せて，ダメなら自分でなんとかする. |
| forwarders | forwarders {192.168.125.xxx; 192.168.125.yyy;}; | forward する相手 |
| recursion | recursion yes; もしくは recursion no; | BIND が再帰的問い合わせを行うかどうか. 行わない場合は純粋にゾーン情報提供者となる. |
| allow-query | allow-query { 192.168.125.xxx; 127.0.0.1; }; | 問い合わせを受け付けるホスト名の列挙. 指定しないと(デフォルト)，どこからでも受け付ける. |
| allow-recursion | allow-recursion { 192.168.125.xxx; 127.0.0.1; }; | 再帰的問い合わせを受け付けるホスト名の列挙. 指定しないと(デフォルト)，どこからでも受け付ける. |
| allow-transfer | allow-transfer { 192.168.125.xxx; 127.0.0.1; }; | ゾーン転送を受け付けるホスト名の列挙. 指定しないと(デフォルト)，どこからでも受け付ける.これは通常は管理者サーバとスレーブサーバのみにしておくのがよいとされる. |
では，次の内容を named.conf の options に足しておこう. ただしその前に named.conf のバックアップを作っておくのを忘れずに.
では，次の内容を named.conf の options に足しておこう.
forward only;
forwarders { 192.168.125.14; };
そして，念の為に named-checkconf でチェックしておこう.
named-checkconf
何も言われなければ，文法上の問題はないということだ. 安心して次へ進もう.
あと，念の為に
named-checkconf -z
ともしておこう(エラーがでるはずだ. 詳しくは後述.).
*** 実習 [#u4df01f8]
上までの作業を行え.
また，上の設定の意味を述べよ(listen-on 設定の意味も調べておこう).
*** named.conf の zone [#c353f1ed]
また，named.conf には zone という項目がある.
これが「自分が管理するゾーン(ドメインと思ってよい)についての情報」を設定するところだ.
ただ，良くみると分かるように，具体的なことは named.conf にはほとんどなく，別に
file "named.root";
などとして読み込むようになっている.
さて，先にまずここでは named.conf での zone について説明しよう.
zone 項目は一般に
zone "ゾーン名(≒ドメイン名)" {
type ゾーンのタイプ;
masters { マスターサーバの IPアドレス }; ← ゾーンタイプが slave の場合
file 具体的な設定内容を書いてあるファイル名;
};
という形をしている.
ゾーン名はまあわかるだろう.
ゾーンのタイプは，全部で hint(ルートサーバ用の特別なものと思ってよい)((より正確には，「情報を自前でもつが，マスターでもスレーブでもない状態」ということだな.)), master(自分がマスターサーバであることを意味する), slave(自分がスレーブサーバであることを意味する) の3種類と思っておけばよい.
masters は，自分がスレーブサーバである場合に，データをくれるマスターサーバを指定するためにある.
file は，自分がマスターサーバの場合は自分で作り，master ディレクトリの下に置く.
自分がスレーブサーバの場合，slave ディレクトリの下にコピーされてくるので，そういうファイル名にしておく.
さて，デフォルトの設定をみると，すでに 3つの特別な zone が設定されている.
そしてそれらを良く読むと，zone "0.0.127.IN-ADDR.ARPA"((自分自身 127.0.0.1 の"上"ドメインの逆引き用)) と zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"((自分自身の"上"ドメインの逆引き用 IPv6 ))の設定が書かれているはずのファイル master/localhost.rev と master/localhost-v6.rev"が存在していないことに気づく.
そこでまずはこれらのファイルを作ろう.
とはいってもとくに考える必要はなくて，root で
cd /etc/namedb
sh ./make-localhost
とすれば自動的にこれらのファイルが作られるようになっているので，そうしよう.
これでとりあえずデフォルト設定 +アルファ が済んだはずなので，まずは
named-checkconf -z
として，エラーがでないかチェックしよう.
** 最低限の起動チェック [#x385dce5]
とりあえず，これで BIND は最低限は動くはず.
ということで，/etc/resolv.conf の nameserver 項目を
nameserver 127.0.0.1
と修正し，/etc/rc.conf に
named_enable="YES"
を適切な場所に書き込んだ上でリブートしよう((昔は named_flags にいろいろ設定しないといけなかったが，今はデフォルトで bind ユーザで chroot されるので，これだけでよい. )).
そして，起動したらまず
ps -axuww | grep /sbin/named
としてみよう.
/usr/sbin/named -t /var/named -u bind
というのが見いだせれば，設定はひとまずうまくいっている.
さらに，
dig www.osaka-u.ac.jp
などとしてみる. そのとき，
; <<>> DiG 9.3.3 <<>> www.osaka-u.ac.jp
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54421
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 3
;; QUESTION SECTION:
;www.osaka-u.ac.jp. IN A
;; ANSWER SECTION:
www.osaka-u.ac.jp. 259111 IN A 133.1.8.18
;; AUTHORITY SECTION:
osaka-u.ac.jp. 259111 IN NS vanilla-ice.odins.osaka-u.ac.jp.
osaka-u.ac.jp. 259111 IN NS ns.osaka-u.ac.jp.
osaka-u.ac.jp. 259111 IN NS ns1.ai3.net.
osaka-u.ac.jp. 259111 IN NS name-server.suita.odins.osaka-u.ac.jp.
osaka-u.ac.jp. 259111 IN NS vanilla-ice.gw.osaka-u.ac.jp.
;; ADDITIONAL SECTION:
ns1.ai3.net. 23282 IN A 202.249.24.33
name-server.suita.odins.osaka-u.ac.jp. 107664 IN A 133.1.119.1
vanilla-ice.odins.osaka-u.ac.jp. 107664 IN A 133.1.192.4
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 24 21:07:10 2008
;; MSG SIZE rcvd: 234
などとなり，(見掛け上は) 127.0.0.1，つまり自分自身が DNS サーバとして問い合わせに答えたことがわかる((実際は知らない情報は全て 192.168.125.14 に任せているわけだが)).
これで，少なくとも BIND の動作が確認できた.
* BIND でゾーン設定 [#bb9cfdca]
さて，BIND の本質的お仕事である，ゾーン(ドメイン)設定をしてみよう.
それでは，各自のマシンで実際にサブドメインを作って管理するような設定で BIND を設定してみよう.
まず，各々のサブドメインは次のようなものとする.
[[授業資料/第03回 ネットワークの設定>授業資料/第03回#i4db58f9]] の PC 番号をもとに，
| 項目 | 設定値 | 備考 |h
| サブドメイン名 | sub&color(red){PC番号};.cl.math.sci.osaka-u.ac.jp | アルファベットの "sub" を番号の前につける. ただし，一桁の場合は 0 がついているので注意. 例えば，PC の番号が 08 の場合，sub08 である. |
| 使える IP | 192.168.125.&color(red){105+(5*PC番号)}; 〜 192.168.125.&color(red){109+(5*PC番号)}; の5つ | 何も全部つかう必要はない. |
| スレーブサーバ | 誰か来ている人と組んで，その人のサーバとする | スレーブサーバは何台あってもよいので，3人，4人で組んでも問題ない |
としよう.
** マスターサーバの設定 - named.conf の設定[#z68e3c67]
例えば，PC 番号が 17 のマシンでは
zone "sub17.cl.math.sci.osaka-u.ac.jp" {
type master;
file "master/sub17.zone";
};
という設定を加えて，zone "sub17.cl.math.sci.osaka-u.ac.jp" の管理を自分で(マスターサーバとして)行う! と宣言する.
もちろん，こうした設定を加えたら
named-checkconf
としてチェックしておこう.
** マスターサーバの設定 - ゾーンファイル の設定 [#y5f96e61]
さて，肝心のゾーンファイルであるが，上の例の場合だと，master/sub17.zone となる.
そこで，既に自動的に作られているファイルを参照して作ろう.
cd /etc/namedb
cd master
cp localhost.rev sub17.zone
として雛形を用意する. それから，sub17.zone を適宜編集して，今の例では
$TTL 3600
@ IN SOA q17.cl.math.sci.osaka-u.ac.jp. root.q17.cl.math.sci.osaka-u.ac.jp. (
2008012403 ; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS q17.cl.math.sci.osaka-u.ac.jp.
test01 IN A 192.168.125.190
などとする.
ちなみに，NS の設定は A などの設定よりも前でないとまずいようだ.
また，NS の設定は FQDN で書くということにも注意しよう.
さて，これは zone 設定ファイルとしては最低限であるが，とりあえずこれで動くはずである.
zone ファイルの書き方であるが，文頭から SOA の ; Minimum まではとりあえず雛形からコピーするのを勧める.
まああまり気にしなくてよいので SOA の中身の意味は授業時に口頭で説明するが，一つだけ SOA で重要なものを説明しておく.
それは SOA の Serial 値である.
これは，このゾーンファイルの「新しさ」を示す値で，これが大きくなるとゾーンファイルが更新されたこととなり，ネットワークに更新された情報が流れることになる.
つまり，ゾーンファイルを編集, 更新したら必ず Serial 値を増やしておかないといけない((Emacs を使ってゾーンファイルを zone モードで編集すると，Serial 値が自動的に増える. ありがたや…)).
次に，全体については，まずつぎの項目を知っていれば大体大丈夫だ.
| 項目 | 説明 |h
| 各行の書き方 | ''名前 IN レコード名 設定'' と書かれることになっている |
| @ | named.conf で指定したそのゾーン名. 上の例だと sub17.cl.math.sci.osaka-u.ac.jp. となる. |
| 何も書いてないところ | @ と解釈される. 分かりにくいが，''IN NS q17.cl.math.sci.osaka-u.ac.jp.'' の行頭がそれに相当する. |
| .で終わっていないマシン名等 | .@ が補われる |
さて，この zone ファイルをチェックしよう.
named-checkzone ゾーン名 チェックしたいゾーンファイル
とすればチェックできる. この例では，
named-checkzone sub17.cl.math.sci.osaka-u.ac.jp ./sub17.zone
として，エラーがでなければよい.
うまくいったら，BIND に設定ファイルを読み直させよう. それには
rndc reload
とすればよい.
さて，動作を確認しよう. それには，他のマシンからこの場合は
dig test01.sub17.cl.math.sci.osaka-u.ac.jp
などとして
;; ANSWER SECTION:
test01.sub17.cl.math.sci.osaka-u.ac.jp. 2959 IN A 192.168.125.190
が得られればよい.
** スレーブサーバの設定 [#vd39019e]
次に，スレーブサーバの設定をしてみよう.
これはマスターより簡単である.
例えば，sub16.cl.math.sci.osaka-u.ac.jp ドメイン(マスターサーバは q16.cl...) のスレーブサーバを q17 が引き受けるとしよう.
この時に行う設定は二カ所だけである.
*** マスター側のゾーンファイルにスレーブサーバを NS として加える. [#qd7d7d0e]
具体的には，
IN NS q17.cl.math.sci.osaka-u.ac.jp.
をサーバ q16 のゾーンファイルに加えておくだけである.
をサーバ q16 のゾーンファイルに加えておくだけである(ただし，レコード A の設定等より前に書いておこう).
*** スレーブ側の named.conf でスレーブサーバ宣言をする [#d29f34e6]
サーバ q17 の named.conf に
zone "sub16.cl.math.sci.osaka-u.ac.jp" {
type slave;
masters { 192.168.125.106; }; ← q16 のアドレス
file "slave/sub16.zone";
};
と書き加えるだけである. "slave/sub16.zone" というファイルは勝手にコピーされてくるので作ったりいじったりしなくてよい(というか，いじってはいけない).
*** 実習 [#nae012af]
誰かと組んで，スレーブサーバ設定まで行え.
また，動作確認を行ってみよ.
具体的には，設定/動作までできたと思ったら，上の例で言えば他のマシンから
dig -t NS sub16.cl.math.sci.osaka-u.ac.jp
などとしてみて，sub16.cl.math.sci.osaka-u.ac.jp の NS として，設定した複数のサーバが表示されることを確認すればよい((他にも，スレーブサーバの /etc/namedb/slave にコピーされてくるはずのゾーンファイルを直接眺めてみるという手もある)).
** 逆引き設定 [#e9f94327]
これは実は「親サーバの事情/設定」で大きく変わってくるのであまり一般的でない… のでとりあえず省略しておく．
*** レポート [#i62ad9c0]
ここまでの作業を行い，なおかつ，作業内容を把握せよ.
今回は NS, A レコードしか設定しなかったが，MX 等も設定してみよ.
また，5つの IP を使いきってみよ.
