授業資料/第10回
これまでの復習 †
これまでの授業に追い付けていない，もしくは理解が完全でない，という学生もいるだろうし，また，冬季休業で授業が空いたことで随分忘れてしまった，という部分もあるだろう.
そこで少し時間を取り，これまでの復習や解説を行う.
DNS の理解 †
さて，ここからは DNS (Domain Name System) について学習しよう.
これまでの授業内容と DNS がわかれば，サーバ設定の「主要な部分の基礎」は分かったことになるだろう*1.
DNS とはホスト名(詳細は後述する)と IP address の対応をはじめとする，
ホスト名とネットワーク構造の対応関係に関する分散データベースとその問い合わせの仕組みである.
日頃 web を使ったりしていて，その全体の仕組みは既におよそ知っているところと思う.
以下で行うサーバの設定も，詳細部分を除けばそんなに難しくはない*2.
そもそも DNS というネットワーク上の分散データベースを必ず利用する必要があるのか †
使っているマシンをインターネットに繋ぐのであればまず必要であると言ってよい.
DNS はインターネットのホスト名を用いてそのホストへアクセスするための事実上の「電話帳」なのである.
逆に言えば，「インターネットに繋がなければ不要なこともある」ので，インターネットに繋がない小さなネットワークを構成する際は DNS 以外の選択肢も検討の余地があることを忘れてはいけない.
また，その電話帳の一部分を「自前のメモに書いておく」ということもでき，しかもこれは DNS と両立が可能である．
これは /etc/hosts というファイルにホスト名と IP Address の対応表を直に書いておく，という手法であり，DNS サーバが不安定であるようなネットワークに居るときには結構有効であるので覚えておくとよい.
なお，/etc/hosts の情報と DNS への問い合わせのどちらを優先するかは /etc/nsswitch.conf ファイルの "hosts" 項目に書かれている順序で設定できる.
デフォルトでは
hosts: files dns
となっており，/etc/hosts を優先するという妥当な設定になっている.
ホスト，ドメイン †
阪大の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 の問い合わせは効率や安全性のために実は結構複雑な仕組みになっているのだが，非
常に大ざっぱに言えば，各々の階層のドメインの情報を受け持つネームサーバ群があり*3，それらがそれぞれ下の階層のネームサーバ群の名前を知っていることでデータベースが分散される形になっている.
そして，DNS server への問い合わせというのは，上のサーバから順々に情報を再帰的に問い合わせて最後の「情報に責任を持っている」ネームサーバ(SOA*4 を提供するサーバのこと)から答えを得るようになっている.
より細かい，正確な話は後述する.
このように，データベースが階層構造をもって分散されていて，誰がどのデータの責任者なのかが最終的に一意に決まり，かつ，そこへ問い合わせが行くようになっているのがDNS の仕組みのよくできているところである*5.
DNS 問い合わせの種類(二種類ある) †
DNS サーバへの問い合わせは，大ざっぱに言って二種類ある.
分かりにくいのでここで書いておこう.
- 再帰的問い合わせ
- 丸投げ的問い合わせ. 聞かれた方は，自分が知らなければ他のサーバに聞き回るなどしていろいろ苦労して最終的な答えを出さないといけない. ただし，さらに誰かに丸投げするのはアリである.
- 非再帰的問い合わせ
- 聞かれる方に負担の少ない問い合わせ. 聞かれた方は，「答えをずばり知っていれば答えを，そうでなければ自分より答えに近そうなネームサーバを知っていればそのネームサーバを教えるだけでよい」.
DNS の仕組みからいって，「誰か一人は再帰的問い合わせに答えて苦労しないといけない」ので，誰がそうするかがポイントとなる.
通常は，DNS 階層のなるべく下に居て再帰的問い合わせを処理できる能力のあるソフトウェアが，つまりたいていは LAN 上の DNS Server などが行うことになる.
DNS から得られる情報 †
基本的には，DNS で(直接に)得られる情報は
| ホスト名を手がかりとした場合は | そのホストの IP アドレスや，メールの宛先ホスト(メールサーバ), ホスト名が別名だった場合は正準名(canonical name), 等 |
| IP Address を手がかりとした場合は | そのホスト名 |
ということになる.
もちろん，DNS に問い合わせる過程で間接的にはより広い情報(例えばそのホストの情報を持っているネームサーバはどれかなど)が得られる.
ここで，上の「得られる情報」についてもう少し情報を記しておこう.
具体的には，次の「レコード名」である. これは，DNS での問い合わせの際に，「その情報が何なのか」を指す重要なタグである.
| レコード名 | 解説 |
| SOA | その情報の責任元の情報. Start of Authority. 責任元サーバ名，管理者メールアドレス，データシリアルナンバー, 種々の有効期限長からなる. |
| A | IP Address |
| AAAA | IP Address(IPv6) |
| NS | ネームサーバ |
| CNAME | そのホストの正準名(≒真の名前) |
| MX | そのアドレス宛にメールが来たらどのメールサーバへ送るべきか. 優先順位番号つき. |
| PTR | ホスト名 |
あと，DNS には時々 "IN" というキーワードが出てくるが，これは Internet という意味なのでまあ気にしなくてよい.
正引き †
ホスト名から IP Address や他の情報を知るために DNS Server に問い合わせることを正引きという.
正引きできないホストというのはインターネット上では(一応)あってはならない.
逆引き †
逆に，IP Address からホスト名や他の情報を知ろうとする問い合わせを逆引きという.
ちなみに，逆引きは必ず出来なければいけないはと規定されていない.
つまり，逆引き出来ない IP Address があっても DNS のルール上は問題ない.
ただ，
- ネットワーク上でそれなりにきちんとしたサーバ等はほとんど逆引きをきちんと設定している
- 逆引き出来ないホストに対しては◯◯のサービスをしない，という設定のサーバが結構ある
- 正引きと逆引きの結果が整合しないといけない，というさらに厳しい設定のサーバも結構ある
- 同様のチェックをパスしないと動かないコマンドもある
などなど，逆引きをきちんと設定しないと困る場面もあるので，逆引きできない状況は避けておきたい.
DNS の状態等を知るツール(1) host †
サーバの設定以前に，DNS 情報を知る方法を一般的に知っておこう.
あまり知られていないように思うが，"host" コマンドが正引き，逆引きともに便利に使える.
例えば
host www.osaka-u.ac.jp
とすると(正引き)
www.osaka-u.ac.jp has address 133.1.8.18
と答え "133.1.8.18" が返ってくるし,
host 133.1.8.18
とすると(逆引き)
18.8.1.133.in-addr.arpa domain name pointer www.osaka-u.ac.jp.
と答え "www.osaka-u.ac.jp." が返ってくる*6.
上記のように，オプション無しだと host コマンドはそっけないが，"-v" オプションをつけるといろいろと情報を出力してくれる.
例えば，
host -v www.osaka-u.ac.jp
とすると, 次のような出力が得られる*7.
Trying "www.osaka-u.ac.jp" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59886 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5 ;; QUESTION SECTION: ;www.osaka-u.ac.jp. IN A ;; ANSWER SECTION: www.osaka-u.ac.jp. 250145 IN A 133.1.8.18 ;; AUTHORITY SECTION: osaka-u.ac.jp. 250145 IN NS name-server.suita.odins.osaka-u.ac.jp. osaka-u.ac.jp. 250145 IN NS ns1.ai3.net. osaka-u.ac.jp. 250145 IN NS vanilla-ice.gw.osaka-u.ac.jp. osaka-u.ac.jp. 250145 IN NS ns.osaka-u.ac.jp. osaka-u.ac.jp. 250145 IN NS vanilla-ice.odins.osaka-u.ac.jp. ;; ADDITIONAL SECTION: vanilla-ice.gw.osaka-u.ac.jp. 83254 IN A 133.1.192.4 vanilla-ice.odins.osaka-u.ac.jp. 83254 IN A 133.1.192.4 ns.osaka-u.ac.jp. 83254 IN A 133.1.192.4 name-server.suita.odins.osaka-u.ac.jp. 83254 IN A 133.1.119.1 ns1.ai3.net. 103140 IN A 202.249.24.33 Received 266 bytes from 192.168.125.14#53 in 0 ms Trying "www.osaka-u.ac.jp" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37870 ;; 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. 1745 IN SOA vanilla-ice.gw.osaka-u.ac.jp. root.osaka-u.ac.jp. 2007112701 10800 1800 3600000 259200 Received 91 bytes from 192.168.125.14#53 in 0 ms Trying "www.osaka-u.ac.jp" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30178 ;; 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. 1745 IN SOA vanilla-ice.gw.osaka-u.ac.jp. root.osaka-u.ac.jp. 2007112701 10800 1800 3600000 259200 Received 91 bytes from 192.168.125.14#53 in 0 ms
ちなみに，DNS 問い合わせ結果表示の中で，"IN" の前にしばしば数ケタの数字が出てくるが，その数字はその情報の残り有効期限(秒単位)，いわば賞味期限である.
他にも，結構多様なオプションがあるので，"man host" として調べておくとよい.
実習 †
適当なホスト名に対して "host -v" で調べた結果を，これまでの知識を元に解釈してみよ.
DNS の状態等を知るツール(2) dig †
近年では，DNS 問い合わせを手で行うコマンドとしては "dig" が一般的である.
使い方は host に似ているがより細かい*8指定が可能だ.
詳しくは "man dig" と "dig -h" で調べてもらうとして，大ざっぱには次のようにつかう.
通常の単なる正引きは
dig www.osaka-u.ac.jp
でよい.
単なる逆引きは "-x" オプションを用いて
dig -x 133.1.8.18
とする.
問い合わせに使う DNS server を指定したいときは，@そのサーバ という文字列をオプションとして加える.
例えば，上の結果から www.osaka-u.ac.jp の情報の責任元である DNS Server は vanilla-ice.gw.osaka-u.ac.jp であることが分かるので*9,このサーバに何か尋ねてみる.
dig @vanilla-ice.gw.osaka-u.ac.jp www.osaka-u.ac.jp
とすると，
; <<>> DiG 9.3.3 <<>> @vanilla-ice.gw.osaka-u.ac.jp www.osaka-u.ac.jp ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35527 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5 ;; QUESTION SECTION: ;www.osaka-u.ac.jp. IN A ;; ANSWER SECTION: www.osaka-u.ac.jp. 259200 IN A 133.1.8.18 ;; AUTHORITY SECTION: osaka-u.ac.jp. 259200 IN NS vanilla-ice.gw.osaka-u.ac.jp. osaka-u.ac.jp. 259200 IN NS vanilla-ice.odins.osaka-u.ac.jp. osaka-u.ac.jp. 259200 IN NS ns.osaka-u.ac.jp. osaka-u.ac.jp. 259200 IN NS name-server.suita.odins.osaka-u.ac.jp. osaka-u.ac.jp. 259200 IN NS ns1.ai3.net. ;; ADDITIONAL SECTION: vanilla-ice.gw.osaka-u.ac.jp. 259200 IN A 133.1.192.4 vanilla-ice.odins.osaka-u.ac.jp. 259200 IN A 133.1.192.4 ns.osaka-u.ac.jp. 259200 IN A 133.1.192.4 name-server.suita.odins.osaka-u.ac.jp. 259200 IN A 133.1.119.1 ns1.ai3.net. 127742 IN A 202.249.24.33 ;; Query time: 1 msec ;; SERVER: 133.1.192.4#53(133.1.192.4) ;; WHEN: Wed Jan 9 23:04:25 2008 ;; MSG SIZE rcvd: 266
となり，自分が責任者である情報については素直に教えてくれることが分かる.
では，少し調子にのってこのネームサーバに他の問い合わせをしてみよう.
例えば，
dig @vanilla-ice.gw.osaka-u.ac.jp www.yahoo.co.jp
としてみる. すると，
; <<>> DiG 9.3.3 <<>> @vanilla-ice.gw.osaka-u.ac.jp www.yahoo.co.jp ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26515 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.yahoo.co.jp. IN A ;; AUTHORITY SECTION: yahoo.co.jp. 47426 IN NS ns10.yahoo.co.jp. yahoo.co.jp. 47426 IN NS dnsg01.yahoo.co.jp. ;; ADDITIONAL SECTION: ns10.yahoo.co.jp. 67433 IN A 210.80.243.9 dnsg01.yahoo.co.jp. 67870 IN A 211.14.12.10 ;; Query time: 2 msec ;; SERVER: 133.1.192.4#53(133.1.192.4) ;; WHEN: Wed Jan 9 23:11:31 2008 ;; MSG SIZE rcvd: 105
となり("ANSWER SECTION" が無いこと，NS は表示されていること，などに注目せよ)，「その情報は僕の管轄じゃないよ. ns10.yahoo.co.jp さんあたりに尋ねてよ」という返答になっていることが分かる*10.
ちなみに，DNS Server がどういう内容にどう返答してくれるかは*11問い合わせ内容とそのサーバと問い合わせる人の関係に依存する.
詳しくは DNS Server の設定を行うと理解できるので，そこまで待とう(ただし，授業時に口頭では説明する).
また，dig は +trace というオプションをつけると生真面目に自分が再帰的動作を行うので，DNS の仕組みを知るのに都合がよい.
もう少し詳しく書くと，このオプション付きでの dig は，問い合わせ先サーバに「非再帰的に答えてね」と頼む(つまり，問い合わせを丸投げしない)*12.
よって各々のサーバは単に手持ちの知識で最もマシな答えを返してくるので，その解釈とつなぎあわせは dig 自身が行うのである.
例えば，
dig +trace www.osaka-u.ac.jp
とすると，
; <<>> DiG 9.3.3 <<>> +trace www.osaka-u.ac.jp ;; global options: printcmd . 10482 IN NS l.root-servers.net. . 10482 IN NS d.root-servers.net. . 10482 IN NS a.root-servers.net. . 10482 IN NS g.root-servers.net. . 10482 IN NS i.root-servers.net. . 10482 IN NS k.root-servers.net. . 10482 IN NS m.root-servers.net. . 10482 IN NS h.root-servers.net. . 10482 IN NS j.root-servers.net. . 10482 IN NS f.root-servers.net. . 10482 IN NS b.root-servers.net. . 10482 IN NS c.root-servers.net. . 10482 IN NS e.root-servers.net. ;; Received 244 bytes from 192.168.125.14#53(192.168.125.14) in 0 ms jp. 172800 IN NS a.dns.jp. jp. 172800 IN NS b.dns.jp. jp. 172800 IN NS d.dns.jp. jp. 172800 IN NS e.dns.jp. jp. 172800 IN NS f.dns.jp. ;; Received 311 bytes from 199.7.83.42#53(l.root-servers.net) in 136 ms osaka-u.ac.jp. 86400 IN NS ns1.ai3.net. osaka-u.ac.jp. 86400 IN NS name-server.suita.odins.osaka-u.ac.jp. osaka-u.ac.jp. 86400 IN NS vanilla-ice.gw.osaka-u.ac.jp. osaka-u.ac.jp. 86400 IN NS vanilla-ice.odins.osaka-u.ac.jp. osaka-u.ac.jp. 86400 IN NS ns.osaka-u.ac.jp. ;; Received 234 bytes from 202.12.30.131#53(b.dns.jp) in 11 ms www.osaka-u.ac.jp. 259200 IN A 133.1.8.18 osaka-u.ac.jp. 259200 IN NS vanilla-ice.gw.osaka-u.ac.jp. osaka-u.ac.jp. 259200 IN NS vanilla-ice.odins.osaka-u.ac.jp. osaka-u.ac.jp. 259200 IN NS ns.osaka-u.ac.jp. osaka-u.ac.jp. 259200 IN NS name-server.suita.odins.osaka-u.ac.jp. osaka-u.ac.jp. 259200 IN NS ns1.ai3.net. ;; Received 266 bytes from 133.1.119.1#53(name-server.suita.odins.osaka-u.ac.jp) in 1 ms
などのような返答が返ってくる.
これをみると，
- 自分がいつも問い合わせる最寄りのサーバ(192.168.125.14)に "." 担当の NS が13台ある*13と教えてもらって，
- その 13台の中の l.root-servers.net に "jp." 担当の NS が5台あると教えてもらって，
- その5台の中の b.dns.jp に "osaka-u.ac.jp." 担当の NS が 5台あると教えてもらって，
- その5台の中の name-server.suita.odins.osaka-u.ac.jp に www.osaka-u.ac.jp. のアドレスを教えてもらった
という流れで検索したことが分かる.
ただし，通常は，なるべくネットワーク上を流れる情報が少なくて済むようにキャッシュなどの様々な工夫が用いられているので，このように馬鹿正直に問い合わせが進むわけではない.
DNS の状態等を知るツール(3) nslookup †
dig が広く知られる前はよく使われていたのがこの "nslookup" コマンドである.
ある条件を満たさない問い合わせをそもそも受け付けないことや，実装が中途半端であることなどから「腐っている」と悪口を言われたりしてあまり使われなくなってきているが，対話モードのお気楽さ等を考えると，まあ，そこまでひどいツールではない(^-^)
むしろ通常ユーザにとっての実用上の一番の欠点は，(古めの nslookup では)逆引きが簡単にできないことであろう*14.
実習 †
dig, nslookup についてマニュアルで調べた後，いくつかのホストについてこれらのコマンドで(正引きで)レコード A, MX について調べてみよ.
また，および得られた IP アドレスを元に逆引きを行ってみよ.
また，自分の携帯のメールアドレスにメールを出す場合，そのメールを受け取るサーバはどこかを調べてみよ.
DNS server の設定(詳細は次回以降) †
さて，DNS server *15ソフトウェアのインストール，設定，稼働にあたりいくつか注意書を書いておく.
DNS server として何を使うか †
DNS server ソフトウェアとしては主に BIND (Berkeley Internet Name Daemon) というものが使われる*16.
この BIND は，BSD 由来のソフトウェアであり，FreeBSD ではデフォルトで入っているので，ほぼ最新の FreeBSD を使っているのであればインストール作業は特に不要である.
ただし，後述するセキュリティの問題があるので，その時利用している BIND のバージョンには特に気を使うようにしよう*17.
あと，混乱しがちであるが，BIND が作るコマンドは named (名前解決のデーモン，とでも思えばよいだろう)という名前であり，マニュアルやディレクトリ名は基本的に "named" という名前が使われるので注意したい.
BIND 設定のための資料 †
なにしろ BIND は古くからあるソフトウェアのため，進化しているとはいってもその設定ファイルの様式は歴史にひきずられた旧態依然とした部分があり，ややわかりにくい*18.
DNS に対する理解ができていない状態で設定ファイルを読むと何がなんだか分からないので，そうした知識取得も兼ねてよい資料に目を通すことを推奨する.
| 名称等 | 備考 |
| FreeBSD システム管理とチューニング(書籍), page 341--374. | たった30ページで DNS の原理から BIND の設定までをきちんとわかりやすく記述したありがたい資料. BIND 8 についての記述なので，最後の方の一部の記述が古くなってしまっている点のみが欠点と言えば欠点. |
| FreeBSD ビギナーズバイブル(改訂第二版)(書籍), page 543--565. | わかりにくい設定の代表格(^-^)である逆引き委譲の仕組みについて詳しく書かれていてありがたい. |
| BIND 9 による DNS サーバ構築(書籍) | とてもわかりやすく書かれていてよい. 本気でお勧め. ただ，逆引きについては「割愛」されているのがとてもとても残念(こんなに分かり易く書ける著者には是非書いて欲しかった) |
| DNS & BIND (書籍) | 定番中の定番. インターネットに繋がって実際にネームサーバとなるサーバを扱うならば買っておかないといけないだろう.ただ，ぱっと読んですぐ理解できるとなどとは期待してはいけない. |
DNS server とセキュリティ †
DNS server というのは古来より cracker の主な攻撃対象の一つであるため，そのセキュリティには特に気を配りたい.
なぜ狙われるかというと，以下のような理由による.
- (理由)
- (解説)
- ネットワークの情報を持っている
- うまくすれば DNS server からネットワーク全体/一部への攻撃の手がかりになる情報を得られる
- root 権限で動作していることが多い
- 乗っ取れればシステムの全権限を握れるし，乗っ取れなくても何かさせることができるかも
- ネットワーク情報を提供している
- server が「嘘の情報」を流すように設定できれば，今流行りの様々な攻撃方法に使える (嘘の web にアクセスさせてパスワードを奪うとかね)
もちろん，DNS server ソフトウェアも(それを用いる OS 側も)対抗して進化しては来ているが，管理者がミスないしは勘違いで設定を「緩く」してしまえばそうした仕組みも意味がなくなる.
であるので，DNS server の設定には注意を払おう.
FreeBSD では，セキュリティ向上のため，BIND についてはデフォルトで次のような対策が施されている.
- 特別なユーザ bind の権限で動作する. root権限ではない.
- /var/named というディレクトリの下に BIND 動作環境が「閉じ込められている」. 本当は /var/named というディレクトリが，BIND から見たら，/ (ルートディレクトリ) に見えるような仕掛けになっている. つまり，BIND がすっかり乗っ取られたとしても，/var/named より上には出られない.
実習 †
DNS サーバの提供するネットワーク情報を「偽装」することで成功するネットワーク攻撃について調べてみよ.
/etc/namedb というディレクトリが実際にはどこにあるか調べよ.
レポート †
ここまでの実習を行い，報告せよ.
また，13 のルートサーバが今どこにあるか(国名，都市名)を調べよ.
また，2002年，2007年のルートサーバへの攻撃について調べよ.
*1 もちろん，ネットワークのルーティングだのパケットフィルタリングだの，この分野で知っていた方がよいことは無限にあると言ってもよい.
*2 ように見えると思う. まあ，委譲(delegation)だのなんだのと言い出すと限りなくややこしくなっていくのだが…
*3 例えば，一番上のルートドメイン階層に担当するネームサーバ(これをルートサーバと言う)は全世界で 13 台ある.
*4 Start of Authority のこと. 「権威の開始」などと訳される.
*5 DNS の仕組みはかなり古いわりに「シンプルながら良くできている」.もちろん細かい問題はあるので，少しずつ改善されていくだろう.
*6 host コマンドは律儀にも最後にドットをつけて表示していることに注意!
*7 結果的に A, AAAA, MX レコードについて尋ねている
*8 というか細かすぎる
*9 必ずわかるとは限らない
*10 これらから，ここからそのサーバへの問い合わせは常に非再帰的問い合わせとして処理されたらしいことがわかる.
*11 もちろん，そのサーバの設定で決まるのだが
*12 逆に言えば，通常の dig コマンドは質問を最寄りの DNS Server に「丸投げ」しているだけで，自分は何も苦労していない.
*13 これは「ルートドメイン担当の総元締 DNS サーバ(全世界で 13台)」. どうやら dig はこの 13台については知らないようだ. フルサービスリゾルバと呼ばれるリゾルバは，たいてい最初からこの 13台を知っている.
*14 最近の nslookup は host コマンドと同じように IP アドレスを渡すだけで逆引きができるようだ.
*15 他には，ネームサーバという名前も良く使われる
*16 もちろん世の中には他のソフトウェアもあるが，BIND の利用率はおよそ 90%あると言われるので，まずは BIND から，という姿勢でよろしかろう.
*17 ちなみに，FreeBSD 6.2 に入っている BIND のバージョンは 9.3.3 であるようだ
*18 とはいっても，DNS を知っていさえすれば設定ファイルを読んで理解できる「気になれる」だけ sendmail の設定ファイルよりは遥かにマシである.
domain-structure-multi.png
domain-structure.png
