授業資料/11
いつものチェック †
いつものように，システムについてまずい点がないかチェック，対応しよう．
具体的には，以前も示した次のコマンドを使うことになる．
- freebsd-update
- portsnap
- portaudit
ただし，portaudit で出てくる警告にすぐ対応すべきかどうかは判断が難しい．セキュリティ上の問題がどれくらいか，ports 等のバージョンアップが間に合っているか，バージョンアップに伴う問題が無いか等々，事前に簡単にで良いので検討してから作業をしよう.
DNS とはなにか? †
今回はインターネットをインターネットたらしめている根幹技術の一つ，DNS (Domain Name System) について学習しよう.
これまでの授業内容に加えてこの DNS がわかれば，サーバ設定の「必要最低限分の基礎」がおおよそわかったといえるかもしれない*1.
さて，DNS とはホスト名(詳細は後述する)と IP address の対応をはじめとする，ホスト名とネットワーク構造の対応関係に関する分散データベースとその問い合わせの仕組みである.
分散した巨大な電話帳を思い浮かべればよいだろう.
日頃 web を使ったりしていて，その役割は既におよそ知っているところと思う.
以下で行うサーバの設定も，詳細部分を除けばそんなに難しくはない*2.
必ず DNS を使わないといけないか? †
使っているマシンをインターネットに繋ぐのであればまず必要であると言ってよい.
DNS はインターネットのホスト名を用いてそのホストへアクセスするための事実上の「電話帳」なのである.
インターネットの巨大さを考えると，他の方法でこの機能を完全に代用するのはほぼ不可能だろう.
逆に言えば，「インターネットに繋がなければ不要なこともある」ので，インターネットに繋がない小さなネットワークを構成する際は DNS 以外の選択肢も検討の余地があることを忘れてはいけない.
/etc/hosts †
ホスト名と IP アドレスの対応などの「ネットワーク電話帳データ」は,「自前のメモに書いておく」こともできる.
これは， /etc/hosts というファイルに書きこむだけでよい.
しかもこれは DNS と両立が可能である．
この方法は DNS サーバが不安定であるようなネットワークに居るときには結構有効であるので覚えておくとよい.
/etc/hosts にホスト名と IPアドレスの対応を書いてある相手に関しては，DNSサーバに接続できない場合でも接続が可能だ. だから，データバックアップをしてくれる相手など，DNSサーバの状態に関係なく接続したい相手の情報は /etc/hosts に書いておくことも良い方法かも知れない.
/etc/hosts のこの便利な性質が，逆に cracker や virus に利用されることがある. 特に ms-windows の virus には /etc/hosts に相当するファイル(C:\WINDOWS\system32\drivers\etc\hosts など)を編集して virus対策ソフトウェアメーカの Web にアクセスできなくするようにするものなどがあるので，ms-windows, MacOS, unix のいずれの OS を使っているにせよ，/etc/hosts ファイル相当のファイルの中身には時々注意を払った方がよい.
なお，/etc/hosts の情報と DNS への問い合わせのどちらを優先するかは /etc/nsswitch.conf ファイルの "hosts" 項目に書かれている順序で設定できる.
デフォルトでは
hosts: files dns
となっており，/etc/hosts を優先するという妥当な設定になっている.
/etc/nsswitch.conf を読んで，上のように設定されていることを確認しておこう.
DNS が「ネットワーク上の分散データベース」の形である必然性 †
ネットワークの巨大さとその変化の早さを考えると，一カ所にデータを集めての管理は事実上無理なことはすぐわかるだろう.
つまり，分散して，なるべく現場に近い部分で各々管理してもらう「分散データベース」
としてのこの形に自然と行き着くことは理解できるだろう.
ホスト，ドメイン †
阪大のwebサーバは www.osaka-u.ac.jp という名称であるが，これを例にして説明しよう.
まず，これは www.osaka-u.ac.jp. と最後にドットをつけた表記が正式であることに注意しておく.
最後のドットは「非常にしばしば」省略されているだけである.
通常ユーザとしてはこれは気にする必要はないが，DNS Server の設定の際には最後のドットを省略すると「間違え」になる場面があるので要注意だ.
普段は意識しなくてよいが，この「最後のピリオド」はネットワーク管理ではあちこちに顔を出すので要注意だ.
さて次にこの中身であるが，これは osaka-u.ac.jp というドメインの中の www というホストであることを意味する.
さらにドメイン部分を詳しく解説すると，正確にはこれは .(ドット) で表されるルートドメインの中に jp ドメインがあり，その中に ac ドメインがあり，さらにその中に osaka-u ドメインがあるという構造をしている.
www.osaka-u.ac.jp. を図で書くと次のようになる(歴史的に より「広い」ドメインを上に描く).
各階層には複数(というか非常に多くの)ドメインが含まれるので，その関係もあわせて描くとつぎのようになる.
ちなみに，www.osaka-u.ac.jp のように，ホスト名+ドメイン名をすべてあわせた形での名称を FQDN(Fully Qualified Domain Name)という.
DNS の問い合わせのおおざっぱな仕組み †
DNS の問い合わせは効率や安全性のために実は結構複雑な仕組みになっているのだが，非常に大ざっぱに言えば，各々の階層のドメインの情報を受け持つネームサーバ群があり, それらがそれぞれ下の階層のネームサーバ群の名前を知っていることでデータベースが分散される形になっている.
そして，DNS server への問い合わせは，上のサーバから順々に情報を再帰的に問い合わせて最後の「情報に責任を持っている」ネームサーバ(SOA: Start of Authority. 「権威の開始」などと直訳される.) を提供するサーバのこと)から答えを得るようになっている(原則としては).
このように，データベースが階層構造をもって分散されていて，誰がどのデータの責任者なのかが最終的に一意に決まり，かつ，そこへ問い合わせが行くようになっているのがDNS の仕組みのよくできているところである.
DNS の仕組みはかなり古いわりに「シンプルながら良くできている」.
とはいえ今となっては様々な問題が出てきているので，少しずつ改善されていくだろう.
DNS 問い合わせの種類(二種類ある) †
DNS サーバへの問い合わせは，大ざっぱに言って二種類ある.
分かりにくいのでここで書いておこう.
- 再帰的問い合わせ
- 丸投げ的問い合わせ. 聞かれた方は，自分が知らなければ他のサーバに聞き回るなどしていろいろ苦労して最終的な答えを出さないといけない. ただし，さらに誰かに丸投げするのはアリである.
- 非再帰的問い合わせ
- 聞かれる方に負担の少ない問い合わせ. 聞かれた方は，「答えをずばり知っていれば答えを，そうでなければ自分より答えに近そうなネームサーバを知っていればそのネームサーバを教えるだけでよい」.
DNS の仕組みからいって，「誰か一人は再帰的問い合わせに答えて苦労しないといけない」ので，誰がそうするかがポイントとなる.
通常は，DNS 階層のなるべく下に居て再帰的問い合わせを処理できる能力のあるソフトウェアが(つまりたいていは LAN 上の DNS Server)が実際に SOA まで再帰的問い合わせを行うか，キャッシュを検索して答えを返すことになる.
DNS から得られる情報 †
基本的には，DNS で(直接に)得られる情報は
| ホスト名を手がかりとした場合は | そのホストの IP アドレスや，メールの宛先ホスト(メールサーバ), ホスト名が別名だった場合は正準名(canonical name), 等 |
| IP Address を手がかりとした場合は | そのホスト名 |
ということになる.
もちろん，DNS に問い合わせる過程で間接的にはより広い情報(例えばそのホストの情報を持っているネームサーバはどれかなど)が得られる.
ここで，上の「得られる情報」についてもう少し情報を記しておこう.
具体的には，次の「レコード名」である. これは，DNS での問い合わせの際に，「その情報が何なのか」を指す重要なタグである.
| レコード名 | 解説 |
| SOA | その情報の責任元の情報. Start of Authority. 責任元サーバ名，管理者メールアドレス，データシリアルナンバー, 種々の有効期限長からなる. |
| A | IP Address |
| AAAA | IP Address(IPv6) |
| NS | ネームサーバ |
| CNAME | そのホストの正準名(≒真の名前) |
| MX | そのアドレス宛にメールが来たらどのメールサーバへ送るべきか. 優先順位番号つき. |
| PTR | ホスト名 |
見逃しがちだが，上の SOA は「得られた情報がどれくらい信用できるのか」を考える際に重要だ(というのも，得られた情報中に SOA が無い場合はその情報はアヤフヤな可能性がそこそこあるからである).
あと，DNS には時々 "IN" というキーワードが出てくるが，これは Internet という意味なのでまあ気にしなくてよい.
正引き †
ホスト名から IP Address や他の情報を知るために DNS Server に問い合わせることを正引きという.
正引きできないホストというのはインターネット上では(一応)あってはならない.
逆引き †
逆に，IP Address からホスト名や他の情報を知ろうとする問い合わせを逆引きという.
ちなみに，逆引きは必ず出来なければいけないはと規定されていない.
つまり，逆引き出来ない IP Address があっても DNS のルール上は問題ない.
ただ，
- ネットワーク上でそれなりにきちんとしたサーバ等はほとんど逆引きをきちんと設定している
- 逆引き出来ないホストに対しては◯◯のサービスをしない，という設定のサーバが結構ある
- 正引きと逆引きの結果が整合しないといけない，というさらに厳しい設定のサーバも結構ある
- 同様のチェックをパスしないと動かないコマンドもある
などなど，逆引きをきちんと設定しないと困る場面もあるので，逆引きできない状況は避けておきたい.
ユーザとして DNS を使ってみる †
DNS の状態等を知るツール(1) host †
サーバの設定以前に，DNS 情報を知る方法を一般的に知っておこう.
あまり知られていないように思うが，"host" コマンドが正引き，逆引きともに便利に使える.
例えば
host www.osaka-u.ac.jp
とすると(正引き)
www.osaka-u.ac.jp has address 133.1.8.5
と答え "133.1.8.5" が返ってくるし,
host 133.1.8.5
とすると(逆引き)
5.8.1.133.in-addr.arpa domain name pointer www.osaka-u.ac.jp.
と答え "www.osaka-u.ac.jp." が返ってくる.
host コマンドは律儀にも最後にドットをつけて表示していることに注意!
上記のように，オプション無しだと host コマンドはそっけないが，"-v" オプションをつけるといろいろと情報を出力してくれる.
例えば，
host -v www.osaka-u.ac.jp
とすると, 次のような出力が得られる(結果的に A, AAAA, MX レコードについて尋ねている)*3.
Trying "www.osaka-u.ac.jp"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45661
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.osaka-u.ac.jp. IN A
;; ANSWER SECTION:
www.osaka-u.ac.jp. 62737 IN A 133.1.8.5
Received 51 bytes from 8.8.8.8#53 in 60 ms
Trying "www.osaka-u.ac.jp"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48978
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;www.osaka-u.ac.jp. IN AAAA
;; AUTHORITY SECTION:
osaka-u.ac.jp. 143 IN SOA a.osaka-u.ac.jp. root.odins.osaka-u.ac.jp. 2011011800 10800 1800 3600000 259200
Received 84 bytes from 8.8.8.8#53 in 51 ms
Trying "www.osaka-u.ac.jp"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33803
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;www.osaka-u.ac.jp. IN MX
;; AUTHORITY SECTION:
osaka-u.ac.jp. 1787 IN SOA a.osaka-u.ac.jp. root.odins.osaka-u.ac.jp. 2011011800 10800 1800 3600000 259200
Received 84 bytes from 8.8.8.8#53 in 51 ms
ちなみに，DNS 問い合わせ結果表示の中で，"IN" の前にしばしば数ケタの数字が出てくるが，その数字はその情報の残り有効期限(秒単位)，いわば賞味期限である.
他にも，結構多様なオプションがあるので，"man host" として調べておくとよい.
まずは上と同じようにして host コマンドを使ってみよう.
また，-v オプションの代わりに -a を使ってみよう.
また，適当なホスト名に対して "host -v" で調べた結果を，これまでの知識を元に解釈してみよ.
DNS の状態等を知るツール(2) dig †
近年では，DNS 問い合わせを手で行うコマンドとしては "dig" が一般的である.
使い方は host に似ているがより細かい*4指定が可能だ.
詳しくは "man dig" と "dig -h" で調べてもらうとして，大ざっぱには次のようにつかう.
"jman dig" とはしないこと! なぜか知らないが，dig に関する日本語マニュアルは相当に古く，オプション等が今のものと全く異なるのだ(全体に日本語マニュアルは古めではあるが，dig のそれは特に古い).
通常の単なる正引きは
dig www.osaka-u.ac.jp
でよい.
単なる逆引きは "-x" オプションを用いて
dig -x 133.1.8.5
とする.
問い合わせに使う DNS server を指定したいときは，@そのサーバ という文字列をオプションとして加える.
例えば，上の結果から www.osaka-u.ac.jp の情報の責任元である DNS Server は a.osaka-u.ac.jp であることが分かるので*5,このサーバに何か尋ねてみる.
dig @a.osaka-u.ac.jp www.osaka-u.ac.jp
とすると，
; <<>> DiG 9.6.2-P2 <<>> @a.osaka-u.ac.jp www.osaka-u.ac.jp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51292
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.osaka-u.ac.jp. IN A
;; ANSWER SECTION:
www.osaka-u.ac.jp. 259200 IN A 133.1.8.5
;; AUTHORITY SECTION:
osaka-u.ac.jp. 259200 IN NS sigw.sinet.ad.jp.
osaka-u.ac.jp. 259200 IN NS b.osaka-u.ac.jp.
osaka-u.ac.jp. 259200 IN NS a.osaka-u.ac.jp.
;; ADDITIONAL SECTION:
a.osaka-u.ac.jp. 259200 IN A 133.1.192.3
b.osaka-u.ac.jp. 259200 IN A 133.1.119.3
;; Query time: 3 msec
;; SERVER: 133.1.192.3#53(133.1.192.3)
;; WHEN: Wed Jan 5 20:18:23 2011
;; MSG SIZE rcvd: 143
となり，自分が責任者である情報については素直に教えてくれることが分かる(status に注目せよ).
では，少し調子にのってこのネームサーバに他の問い合わせをしてみよう.
例えば，
dig @a.osaka-u.ac.jp www.yahoo.co.jp
としてみる. すると，
; <<>> DiG 9.6.2-P2 <<>> @a.osaka-u.ac.jp www.yahoo.co.jp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 61423
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.yahoo.co.jp. IN A
;; Query time: 3 msec
;; SERVER: 133.1.192.3#53(133.1.192.3)
;; WHEN: Wed Jan 5 20:18:45 2011
;; MSG SIZE rcvd: 33
となり("ANSWER SECTION" が無いこと，status が "REFUSED" になっていること，などに注目せよ)，「その情報は僕の管轄じゃないよ」という返答になっていることが分かる.
ちなみに，DNS Server がどういう内容にどう返答してくれるかは問い合わせ内容とそのサーバの設定と問い合わせる人の関係に依存する. 詳しくはあとでわかるだろう．
さて，dig は +trace というオプションをつけると生真面目に自分が再帰的動作を行うので，DNS の仕組みを知るのに都合がよい.
もう少し詳しく書くと，このオプション付きでの dig は，問い合わせ先サーバに「非再帰的に答えてね」と頼む(つまり，問い合わせを丸投げしない).
逆に言えば，通常の dig コマンドは質問を最寄りの DNS Serverに「丸投げ」しているだけで，自分は何も苦労していないのだ.
つまり，+trace つきで dig コマンドを使ったときは，各々のサーバは単に手持ちの知識で最もマシな答えを返してくるので，その解釈とつなぎあわせは dig 自身が行うのである.
例えば，
dig +trace www.osaka-u.ac.jp
とすると，
; <<>> DiG 9.6.2-P2 <<>> +trace www.osaka-u.ac.jp
;; global options: +cmd
. 3103 IN NS a.root-servers.net.
. 3103 IN NS b.root-servers.net.
. 3103 IN NS c.root-servers.net.
. 3103 IN NS d.root-servers.net.
. 3103 IN NS e.root-servers.net.
. 3103 IN NS f.root-servers.net.
. 3103 IN NS g.root-servers.net.
. 3103 IN NS h.root-servers.net.
. 3103 IN NS i.root-servers.net.
. 3103 IN NS j.root-servers.net.
. 3103 IN NS k.root-servers.net.
. 3103 IN NS l.root-servers.net.
. 3103 IN NS m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 50 ms
jp. 172800 IN NS a.dns.jp.
jp. 172800 IN NS b.dns.jp.
jp. 172800 IN NS c.dns.jp.
jp. 172800 IN NS d.dns.jp.
jp. 172800 IN NS e.dns.jp.
jp. 172800 IN NS f.dns.jp.
jp. 172800 IN NS g.dns.jp.
;; Received 431 bytes from 198.41.0.4#53(a.root-servers.net) in 65 ms
osaka-u.ac.jp. 86400 IN NS b.osaka-u.ac.jp.
osaka-u.ac.jp. 86400 IN NS a.osaka-u.ac.jp.
osaka-u.ac.jp. 86400 IN NS sigw.sinet.ad.jp.
;; Received 127 bytes from 210.138.175.244#53(d.dns.jp) in 18 ms
www.osaka-u.ac.jp. 259200 IN A 133.1.8.5
osaka-u.ac.jp. 259200 IN NS sigw.sinet.ad.jp.
osaka-u.ac.jp. 259200 IN NS b.osaka-u.ac.jp.
osaka-u.ac.jp. 259200 IN NS a.osaka-u.ac.jp.
;; Received 143 bytes from 133.1.119.3#53(b.osaka-u.ac.jp) in 3 ms
などのような返答が返ってくる.
これをみると，
- 使っている DNS サーバ(この場合は例として 8.8.8.8 を使っている)への問い合わせの結果としてまず "."(ルートドメイン)担当の NS
が 13台あることを知る(フルサービスリゾルバと呼ばれるリゾルバは，たいてい最初からこの 13台を知っている). - その 13台の中の a.root-servers.net に "jp." 担当の NS が 7台あると教えてもらって，
- その 7台の中の d.dns.jp に "osaka-u.ac.jp." 担当の NS が 3台あると教えてもらって，
- その 3台の中の b.osaka-u.ac.jp に www.osaka-u.ac.jp. のアドレスを教えてもらった
という流れで検索したことがよく分かる.
ただし，通常は，なるべくネットワーク上を流れる情報が少なくて済むようにキャッシュなどの様々な工夫が用いられているので，このように馬鹿正直に問い合わせが進むわけではない.
ルートサーバの重要性とセキュリティ †
ここで，上に出てきたルートドメイン担当の DNSサーバ(ルートサーバと呼ばれる)について記述しておこう.
このルートサーバは，DNS の総元締であるので，これらがきちんと機能しないとインターネットそのものがきちんと機能しない. "The Internet" の「要」といってよいだろう.
また逆に言えば，インターネットへの攻撃者からみればルートドメインこそが攻撃対象として最も重要なものの一つということになる.
そのため，これまでにも大規模の各種攻撃にたびたびさらされている.
しかし，13台が世界各地に散っていることや使用するソフトウェアを「わざと異なるものにしてある」ことなどから持ち堪えてきたという歴史がある.
ルートサーバに対するこれまで加えられた攻撃やその経緯について調べておこう. セキュリティを保つためにどうすればよいかという良い学習資料になるはずだ.
ちなみに，インターネットを支えるルートドメイン担当サーバ13*6の管理機関うちわけは，かつてはアメリカが 10, 日本が 1, ノルウェーが 1, オランダが 1 であるとされていた(今はかなり分担がすすみ，1つのルートドメインをいくつもの国の組織で支えるようになってきているので，このような単純な分類は難しい).
こうした情報は http://www.root-servers.org/ にリストがあるので，気になる人は見てみよう.
DNS の状態等を知るツール(3) nslookup †
dig が広く知られる前はよく使われていたのがこの "nslookup" コマンドである.
ある条件を満たさない問い合わせをそもそも受け付けないことや，実装が中途半端であることなどから「腐っている」と悪口を言われたりしてあまり使われなくなってきているが，cygwin にも載っていることや対話モードのお気楽さ等を考えると，まあ，そこまでひどいツールではない(^-^)
"man nslookup" として nslookup のマニュアルを読んでおこう.
host, dig, nslookup についてマニュアルで調べた後，いくつかのホストについてこれらのコマンドで(正引きで)レコード A, MX について調べてみよ.
また，および得られた IP アドレスを元に逆引きを行ってみよ.
また，自分の携帯のメールアドレスにメールを出す場合，そのメールを受け取るサーバはどこかを調べてみよ.
DNS 逆引きの仕組み †
BIND の設定を始める前に，逆引きの仕組みについても触れておこう.
実は，利用者のよくある直感と異なり，DNS の逆引き(IP アドレスから他の情報を知る)に特別な仕組みは用意されていない.
IP アドレスも FQDN のように階層構造をしていることを利用して，
「IP アドレスもホスト名の一種であるとみなして DNS の仕組みに紛れ込ませる」
ことで逆引きを実現している.
具体的には，"in-addr.arpa." という逆引き専用の特別なドメインの下に，IP アドレスを逆向きにしてホスト名とみなして DNS で取り扱う.
ドメインのツリー構造と，IP のツリー構造の向きが「逆」なことに注意せよ.
例えば，192.168.125.91 という IP アドレスは，91.125.168.192.in-addr.arpa. というホスト名で DNS で登録，検索されることになる.
逆引き設定ではこの知識が必要なので覚えておこう.
dig コマンドなどで，上の仕組みを実感してみよう.
具体的には，例えばマシン q01.cl.math.sci.osaka-u.ac.jp = 192.168.125.91 に対して
host -t PTR 91.125.168.192.in-addr.arpa.
とすると，
91.125.168.192.in-addr.arpa domain name pointer q01.cl.math.sci.osaka-u.ac.jp.
として，確かにこの引き方で答えが返ってくることが分かる.
(ただし，これを毎回やるのは面倒だからか，たいていのコマンドは IP アドレスをそのまま直接入力してもコマンド側で解釈し直してくれる)
同様に，dig コマンドでも，
dig -t PTR 91.125.168.192.in-addr.arpa.
とすればよいし，nslookup コマンドでも，
nslookup -q=PTR 91.125.168.192.in-addr.arpa.
とすれば，本来の形での逆引きができる.
上の例では，問い合わせタイプをレコード "PTR" にしているが，これは "ANY" にしてもよいだろう.
自分のマシンの IP アドレスを使って，上の host, dig, nslookup コマンドを行ない，自分のマシン名がきちんと返ってくるか確かめてみよう.
DNS 問い合わせクライアントの設定 †
サーバ BINDの設定の前に，DNS の問い合わせの設定は FreeBSD でどのようにされているか書いておこう.
FreeBSD では DNS 問い合わせを行う時の設定は基本的に /etc/resolv.conf というファイルに書き込むことになっている.
詳細は man resolv.conf もしくは jman resolv.conf としてマニュアルを読んでもらうことにして，最低限の説明を書いておこう.
| オプション | 例(どれも1行で書かれる) | 説明 |
| 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 とは排他的. |
/etc/resolv.conf の search オプションを設定して，活用してみよう.
具体的には，
search cl.math.sci.osaka-u.ac.jp math.sci.osaka-u.ac.jp sci.osaka-u.ac.jp
という行を /etc/resolv.conf に加えた後，
1行で書くこと!
host www
や
dig +search -t ANY mail
などとしてみよう.
dig コマンドは，デフォルトでは search オプションを無視するので, +search としておく.
DNS サーバの多重化 †
さて，そろそろ DNS サーバの話に移ろう.
まず DNS サーバの多重化について述べておこう.
DNS サーバはインターネットで非常に重要な役割を果たすものであるので，あるドメイン情報を公的に管理しているサーバが 1台しかない，という状態はあまりにも心細く，避けるべきである.
そこで，公的な DNS サーバは基本的に2箇所以上に多重化することになっている.
いままで dig 等で DNS 情報を見たときに，どのドメインの担当サーバも複数あったことを思い出そう.
そして，多重化した際のデータの整合性や更新についても，きちんとした仕組みが考えられている.
これは，1つのゾーン(1つの DNS 情報の責任範囲と思えばよい)について，そのオリジナル情報をもつサーバ マスターサーバ を1台と，そのコピー情報をもつサーバ スレーブサーバ を 1台以上用意すること，として実現される.
そうして，オリジナル情報がマスターサーバからスレーブサーバに定期的ないしは更新時にすぐコピーされることで，これら複数のサーバがほぼ同じ情報を持つ仕組みになっている.
これをゾーン転送という.ゾーン転送も DNS サーバの仕事なので，人間が手を下す必要は特にない.
なお，DNS 問い合わせを行うクライアントから見るとマスターサーバかスレーブサーバかの区別はあまり無く，単に「早く答えた奴」などから答えを得るようになっている.
DNS サーバの親子関係 †
次に，DNS サーバの親子関係について述べよう.
各々の DNS サーバが局所的な情報を持っているだけで全体がうまくいく仕組みのポイントがこれであるので，しっかり理解しよう.
まず，DNS が階層的であり，その情報を管理する DNS サーバも階層的になっていることは先の授業の dig +trace の例で理解できているだろう.
さて，ではその階層，親子関係(親がより大きなドメインを，子はその中のサブドメインを管理しているサーバということになる)は実際にどのように管理されているだろうか.
これは，「親サーバが，子サーバがサブドメインを管理していることを知ってさえいればよい」ことを利用して管理されている.
子は親を直接知る必要はない. なんなら一番上の祖先(ルートサーバ13台)からたどれば済むのだから.
具体的には，親サーバのそのゾーン(ドメイン)情報の中に，子サーバが管理するゾーン(ドメイン)とその子サーバの対応が書かれていればよい.
これが DNS サーバ管理の一番のポイントだ. ここさえわかれば実はそんなに難しくない.
分かり易いように具体例で書こう.
例えば，ある親サーバが 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. にアクセスできないので意味がない.
さて，この話を逆に言えば，
「親サーバが，子サーバが(サブ)ドメインを管理していることを知らない」= 「親サーバで上のような設定をしていない」
状況では，その(サブ)ドメインの情報は「子サーバに直接問い合わせる人たちしか知らない」ので，あくまでローカルな情報ということになる．
よって，例えば研究室内や自宅内でのみ通用するマシンの名前やサブドメインなどは，こうして管理する形になる.
もちろん，この場合はこのサブドメイン情報を使って外からアクセスすることはできない.
ちなみに，今回の授業ではこちらの形の設定を行う．
DNS サーバのソフトウェアについて †
DNS server ソフトウェアとしては主に BIND (Berkeley Internet Name Daemon) というものが使われる．
もちろん世の中には他のソフトウェアもあるが，BIND の利用率はおよそ 90%あると言われるので，公的な DNS サーバを動かすならば BIND でよろしかろう.
この BIND は，BSD 由来のソフトウェアであり，FreeBSD ではデフォルトで入っているので，ほぼ最新の FreeBSD を使っているのであればインストール作業は特に不要である.
ただし，後述するセキュリティの問題があるので，その時利用している BIND のバージョンには特に気を使うようにしよう.
しかし，この BIND は機能が完全な分だけ設定がやや大変だ．
もちろん，インターネットに完全に接続する大規模なシステムでは BIND を使うのが良いのだが，近年の DNS サーバの需要はむしろインターネットにドメインの情報をあまり渡さない形のDNS サーバ，すなわち LAN の「内側」向けのものの方が多いだろう．
これは先に例に挙げた，大学の研究室内部や，個人の自宅内，中小企業の社内向け DNSサーバなどが該当する．
こうした「外に向けて情報を伝える必要の無い」，すなわち「DNS サーバの親子関係に組み込まれない」DNS サーバには，よりシンプルで使いやすいソフトウェア dnsmasq があるので今回はそちらを使おう．
dnsmasq には DHCP サーバとしての機能もあり，DNS サーバと DHCP サーバが自然に統合できるという点では BIND より優れている．DHCP サーバ部分については今回は解説しないが，上に述べたような小さな環境で使う場合は便利なこともあるので，調べておくとよいだろう．
実は，皆が自宅で導入しているルーター(多くは契約しているプロバイダからのレンタルだろう)用の有名なオープンシステム OpenWRT の中ではこの dnsmasq が使われていたりする．
なお，BIND を使いたいような場合は，前年度の授業資料を参照されたい．
dnsmasq のインストールと設定 †
インストール前の準備 †
まずは先に述べた BIND が既に動いていたりしないかチェックしよう．
lsof -i4 | less ps -axuww | less
などとして，"named" というデーモン(BIND のこと)が動いていないか確認しよう．
混乱しがちであるが，BIND が作るコマンドは named (名前解決のデーモン，とでも思えばよいだろう)という名前であり，マニュアルやディレクトリ名は基本的に "named" という名前が使われるので注意したい.
そして BIND が動いているような場合は kill コマンドなどを用いて動作を停め，さらに /etc/rc.conf を修正して次回起動時からは BIND が動かないようにしよう(BIND が動いているならばおそらく rc.conf 中に named_enable="YES" という設定があるはずだからこの設定を変更すれば良い)．
BIND をアンインストールする必要はない．
インストール †
いつものように portsnap をきちんとしてから，
portinstall dnsmasq
で大丈夫なはず．
その際，オプションを聞かれるが，
のように IPv6 を外しておけばよいだろう．
さて，インストール時に出てくるメッセージ(ログを見ると良い)で重要そうなのは
*** To enable dnsmasq, edit /usr/local/etc/dnsmasq.conf and
*** set dnsmasq_enable="YES" in /etc/rc.conf[.local]
と
===> SECURITY REPORT:
This port has installed the following files which may act as network
servers and may therefore pose a remote security risk to the system.
/usr/local/sbin/dnsmasq
This port has installed the following startup scripts which may cause
these network services to be started at boot time.
/usr/local/etc/rc.d/dnsmasq
If there are vulnerabilities in these programs there may be a security
risk to the system. FreeBSD makes no guarantee about the security of
ports included in the Ports Collection. Please type 'make deinstall'
to deinstall the port if this is a concern.
For more information, and contact details about the security
status of this software, see the following webpage:
というあたりだ．
最初の項目で，
- dnsmasq の設定ファイルは /usr/local/etc/dnsmasq.conf である．
- dnsmasq を有効にするには，/etc/rc.conf に dnsmasq_enable="YES" と書けば良い．
ということがわかり，次の項目で
- dnsmasq の起動スクリプトは /usr/local/etc/rc.d/dnsmasq である．
ことがわかる．
設定 †
さて，dnsmasq を利用するための最低限の設定をまずは行おう．
dnsmasq の設定のデフォルトは非常に素直なので，最低限として
- /etc/hosts 中の dnsmasq が理解出来ない設定を削除しておく
- 起動時に dnsmasq が動作を始めるようにする
- 名前解決を dnsmasq に頼むように設定する
という設定だけしておけばまずは使えるはずだ．
以下の設定を実際に行おう．
/etc/hosts 中の dnsmasq が理解出来ない設定を削除しておく †
/etc/hosts 中には，IPv6 の設定が時々紛れ込んでいたりする．
通常は特に害はないが，(IPv6 オプションを外した) dnsmasq ではそうした設定が理解出来なかったりするのでそうした設定は無効にしておいたほうが良い．
具体的には，/etc/hosts 中に
::1 localhost ほげほげ…
という行がある場合，この行を無効にしておくことになる(この行の先頭に # という文字を入れればよい)．
起動時に dnsmasq が動作を始めるようにする †
これは先のメッセージから明らかなように，
dnsmasq_enable="YES"
を /etc/rc.conf に書いて再起動すればよい．
名前解決を dnsmasq に頼むように設定する †
/etc/resolv.conf の先頭行に
nameserver 127.0.0.1
を書きこんでおけば，DNS の名前解決をまずは(自分自身の上で動いている) dnsmasq に頼むことになる．
IP アドレス 127.0.0.1 というのは自分自身のことだ．
この設定は，"nameserver ..." という設定の中で最初に出てこないといけないので，先頭行にという指示には意味がある．
既に書いてあるはずの "nameserver ..." という設定は書き換えたり消したりしないように！ この情報は，dnsmasq が「外へ情報を聞きに行く」ときに使うもので，これがないと DNS サーバとしてほとんど意味がなくなる．
dnsmasq が動いているか確認 †
BIND の動作チェックを行った時同様に，
lsof -i4 | less ps -axuww | less
として dnsmasq が動いているかチェックしよう．
動いていないようならば設定を確認しよう．
動かしてみる †
さて，既に dnsmasq が動いているならばこれだけの設定で意識せずに dnsmasq が使えるはずだ．
そこで，以下のようにして確認してみよう．
例えば，
dig www.osaka-u.ac.jp
とすれば
; <<>> DiG 9.6.2-P2 <<>> www.osaka-u.ac.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10480
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.osaka-u.ac.jp. IN A
;; ANSWER SECTION:
www.osaka-u.ac.jp. 58211 IN A 133.1.8.5
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jan 26 19:41:24 2011
;; MSG SIZE rcvd: 51
というように，127.0.0.1(自分自身)が解答を返すので，自分自身の上で DNS 解決を行うソフトウェアが動いていることになり，dnsmasq が答えたことがわかる．
dnsmasq が管轄するホスト情報を追加してみよう †
設定がやや面倒な BIND とは異なり，dnsmasq では dnsmasq が管轄するホスト情報は /etc/hosts に書き加えるだけで良い．
そこで，その作業をやってみよう．
個人個人で異なるようにするため，/etc/hosts ファイルに，
| 項目 | 設定値 | 備考 |
| 追加するホスト名(3つ) | sub01-今のホスト名 から sub03-今のホスト名 | 例えば，q05.cl.math.sci.osaka-u.ac.jp を使っている人は，sub01-q05.cl.math.sci.osaka-u.ac.jp, sub02-q05.cl.math.sci.osaka-u.ac.jp, sub03-q05.cl.math.sci.osaka-u.ac.jp の3つ． |
| それらホストの IP | 192.168.125.110+(3*PC番号) から 192.168.125.112+(3*PC番号) の3つ． | 例えば q05 を使っている人は，192.168.125.125, 192.168.125.126, 192.168.125.127 となる． |
の設定を追加しよう．
これは具体的には，例えば q05 を使っている人は
192.168.125.125 sub01-q05 sub01-q05.cl.math.sci.osaka-u.ac.jp 192.168.125.126 sub02-q05 sub02-q05.cl.math.sci.osaka-u.ac.jp 192.168.125.127 sub03-q05 sub03-q05.cl.math.sci.osaka-u.ac.jp
という3行を書き込むことになる(IP とホスト名の間はおそらくタブ2つぐらいで区切るのが良いだろう)．
この設定を行ったあと，書き換えた設定を読み込ませるために dnsmasq を再起動しておこう．具体的には，
/usr/local/etc/rc.d/dnsmasq restart
とすればよい．
追加した情報を自分自身が知ることができるかチェックしよう †
dig コマンドを使ってチェックしよう．
例えば，q05 を使っている人は，
dig sub02-q05
などとしてみよう．
返答の ANSWER SECTION に正しい答えが返ってきていれば，きちんと動いていることが確認できる．
追加した情報を他マシンが(直接)問い合わせられるかチェックしよう †
自分の /etc/hosts に書いた情報を自分で引けるのは DNS サーバと関係なくもとからできることだから，ここまでの動作では DNS サーバ dnsmasq を導入したありがたみがわからない．
そこで，dnsmasq が LAN 内の DNS サーバとして動くイメージを掴むために，他の人のマシンに問い合わせを行ってみよう．
例えば，q05 以外 を使っている人が q05 を DNS サーバとして使うイメージでチェックを行うならば，
dig @q05 sub03-q05
としてみればよい．
返答の ANSWER SECTION に正しい答えが返ってきていれば，q05 が(汎用) DNS サーバとして使えることと q05 の上で設定した値を知ることができることがわかる．
レポート †
途中で「調べよ」等と指示された事項について調査を行い，報告せよ.
もちろん各自の
- 所属(学部，学科)
- 学籍番号
- 学年
- 氏名
- 日時
- 肝心のレポート内容(得た知見，作業について気づいたこと等)
を書くのを忘れないように.
about Icons, ClipArts †
Some icons in this page are downloadable at ICONFINDER.
The "note" icon designed by Marco Martin is distributed with the LGPL licence,
the "warning" icon designed by Alexandre Moore with the GPL licence
and the "triangle" icon 
designed by Joseph North is distributed with the Creative Commons (Attribution-Noncommercial-Share Alike 3.0 Unported) licence.
Some clip arts used in this page are downloadable at Open Clip Art Library.
We deeply appreciate their superb works. With licence, they describe that "the actual clipart content on open clipart library is Public domain" in the web.
*1 もちろん，ネットワークのルーティングだのパケットフィルタリングだの，この分野で知っていた方がよいことは無限にあると言ってもよい.
*2 ように見えると思う. まあ，委譲(delegation)だのなんだのと言い出すと限りなくややこしくなっていくのだが…
*3 試しに，google public DNS を使ってみた例
*4 というか細かすぎる
*5 必ずわかるとは限らない
*6 …といってもマシンが13台というわけではなく，外からはそう見えるようになっているというだけで，実態はもっと多い
添付ファイル:
domain-structure-multi.png 99件
[詳細]
DNS-model.png 127件
[詳細]
inverse-IPdomain.png 104件
[詳細]
domain-structure.png 105件
[詳細]
dnsmasq-options.png 1100件
[詳細]
