#contents
** これまでの復習 [#jf62a8c4]
これまでの授業に追い付けていない，もしくは理解が完全でない，という学生もいるだろうし，また，冬季休業で授業が空いたことで随分忘れてしまった，という部分もあるだろう.
そこで少し時間を取り，これまでの復習や解説を行う.
* DNS とはなにか? [#mef86f0c]
今回は DNS (Domain Name System) について学習しよう.
これまでの授業内容に加えてこの DNS がわかれば，サーバ設定の「必要最低限分の基礎」がおおよそわかったといえるかもしれない((もちろん，ネットワークのルーティングだのパケットフィルタリングだの，この分野で知っていた方がよいことは無限にあると言ってもよい.)).
さて，DNS とはホスト名(詳細は後述する)と IP address の対応をはじめとする，ホスト名とネットワーク構造の対応関係に関する分散データベースとその問い合わせの仕組みである.
分散した巨大な電話帳を思い浮かべればよいだろう.
日頃 web を使ったりしていて，その役割は既におよそ知っているところと思う.
#br
CENTER:&ref(./DNS-model.png,80%);
CENTER:DNS の基礎的な役割
#br
以下で行うサーバの設定も，詳細部分を除けばそんなに難しくはない((ように見えると思う. まあ，委譲(delegation)だのなんだのと言い出すと限りなくややこしくなっていくのだが…)).
** 必ず DNS を使わないといけないか? [#x4b9ec6f]
** 必ず DNS を使わないといけないか? [#d7dbc108]
使っているマシンをインターネットに繋ぐのであればまず必要であると言ってよい.
DNS はインターネットのホスト名を用いてそのホストへアクセスするための事実上の「電話帳」なのである.
インターネットの巨大さを考えると，他の方法でこの機能を完全に代用するのはほぼ不可能だろう.
逆に言えば，「インターネットに繋がなければ不要なこともある」ので，インターネットに繋がない小さなネットワークを構成する際は DNS 以外の選択肢も検討の余地があることを忘れてはいけない.
** /etc/hosts [#p33b1899]
** /etc/hosts [#fff8eac9]
ホスト名と IP アドレスの対応などの「ネットワーク電話帳データ」は,「自前のメモに書いておく」こともできる.
これは， /etc/hosts というファイルに書きこむだけでよい.
しかもこれは DNS と両立が可能である．
この方法は DNS サーバが不安定であるようなネットワークに居るときには結構有効であるので覚えておくとよい.
&ref(./warning.png); /etc/hosts にホスト名と IPアドレスの対応を書いてある相手に関しては，DNSサーバに接続できない場合でも接続が可能だ. だから，データバックアップをしてくれる相手など，DNSサーバの状態に関係なく接続したい相手の情報は /etc/hosts に書いておくことも良い方法かも知れない.
&br;
&ref(./warning.png); /etc/hosts のこの便利な性質が，逆に cracker や virus に利用されることがある. 特に ms-windows の virus には /etc/hosts に相当するファイル(C:\WINDOWS\system32\drivers\etc\hosts など)を編集して virus対策ソフトウェアメーカの Web にアクセスできなくするようにするものなどがあるので，ms-windows, MacOS, unix のいずれの OS を使っているにせよ，/etc/hosts ファイル相当のファイルの中身には時々注意を払った方がよい.
&br;
なお，/etc/hosts の情報と DNS への問い合わせのどちらを優先するかは /etc/nsswitch.conf ファイルの "hosts" 項目に書かれている順序で設定できる.
デフォルトでは
hosts: files dns
となっており，/etc/hosts を優先するという妥当な設定になっている.
&ref(./notes.png); /etc/nsswitch.conf を読んで，上のように設定されていることを確認しておこう.
** DNS が「ネットワーク上の分散データベース」の形である必然性 [#nd7f1da8]
ネットワークの巨大さとその変化の早さを考えると，一カ所にデータを集めての管理は事実上無理なことはすぐわかるだろう.
つまり，分散して，なるべく現場に近い部分で各々管理してもらう「分散データベース」
としてのこの形に自然と行き着くことは理解できるだろう.
** ホスト，ドメイン [#j91fea61]
阪大のwebサーバは www.osaka-u.ac.jp という名称であるが，これを例にして説明しよう.
まず，これは www.osaka-u.ac.jp. と最後にドットをつけた表記が正式であることに注意しておく.
最後のドットは「非常にしばしば」省略されているだけである.
通常ユーザとしてはこれは気にする必要はないが，DNS Server の設定の際には最後のドットを省略すると「間違え」になる場面があるので要注意だ.
&ref(./warning.png); 普段は意識しなくてよいが，この「最後のピリオド」はネットワーク管理ではあちこちに顔を出すので要注意だ.
さて次にこの中身であるが，これは osaka-u.ac.jp というドメインの中の www というホストであることを意味する.
さらにドメイン部分を詳しく解説すると，正確にはこれは .(ドット) で表されるルートドメインの中に jp ドメインがあり，その中に ac ドメインがあり，さらにその中に osaka-u ドメインがあるという構造をしている.
www.osaka-u.ac.jp. を図で書くと次のようになる(歴史的に より「広い」ドメインを上に描く).
CENTER:&ref(./domain-structure.png);
各階層には複数(というか非常に多くの)ドメインが含まれるので，その関係もあわせて描くとつぎのようになる.
CENTER:&ref(./domain-structure-multi.png);
ちなみに，www.osaka-u.ac.jp のように，ホスト名+ドメイン名をすべてあわせた形での名称を FQDN(Fully Qualified Domain Name)という.
** DNS の問い合わせのおおざっぱな仕組み [#c9cc067d]
DNS の問い合わせは効率や安全性のために実は結構複雑な仕組みになっているのだが，非常に大ざっぱに言えば，各々の階層のドメインの情報を受け持つネームサーバ群があり, それらがそれぞれ下の階層のネームサーバ群の名前を知っていることでデータベースが分散される形になっている.
そして，DNS server への問い合わせというのは，上のサーバから順々に情報を再帰的に問い合わせて最後の「情報に責任を持っている」ネームサーバ(SOA: Start of Authority. 「権威の開始」などと直訳される.) を提供するサーバのこと)から答えを得るようになっている.
より細かい，正確な話はサーバ設定時に後述する.
このように，データベースが階層構造をもって分散されていて，誰がどのデータの責任者なのかが最終的に一意に決まり，かつ，そこへ問い合わせが行くようになっているのがDNS の仕組みのよくできているところである.
DNS の仕組みはかなり古いわりに「シンプルながら良くできている」.
もちろん細かい問題はあるので，少しずつ改善されていくだろう.
** DNS 問い合わせの種類(二種類ある) [#be3ea513]
DNS サーバへの問い合わせは，大ざっぱに言って二種類ある.
分かりにくいのでここで書いておこう.
: 再帰的問い合わせ | 丸投げ的問い合わせ. 聞かれた方は，自分が知らなければ他のサーバに聞き回るなどしていろいろ苦労して最終的な答えを出さないといけない. ただし，さらに誰かに丸投げするのはアリである.
: 非再帰的問い合わせ | 聞かれる方に負担の少ない問い合わせ. 聞かれた方は，「答えをずばり知っていれば答えを，そうでなければ自分より答えに近そうなネームサーバを知っていればそのネームサーバを教えるだけでよい」.
DNS の仕組みからいって，「誰か一人は再帰的問い合わせに答えて苦労しないといけない」ので，誰がそうするかがポイントとなる.
通常は，DNS 階層のなるべく下に居て再帰的問い合わせを処理できる能力のあるソフトウェアが，つまりたいていは LAN 上の DNS Server などが行うことになる.
** DNS から得られる情報 [#oc094b9b]
基本的には，DNS で(直接に)得られる情報は
| ホスト名を手がかりとした場合は | そのホストの IP アドレスや，メールの宛先ホスト(メールサーバ), ホスト名が別名だった場合は正準名(canonical name), 等 |
| IP Address を手がかりとした場合は | そのホスト名 |
ということになる.
もちろん，DNS に問い合わせる過程で間接的にはより広い情報(例えばそのホストの情報を持っているネームサーバはどれかなど)が得られる.
ここで，上の「得られる情報」についてもう少し情報を記しておこう.
具体的には，次の「レコード名」である. これは，DNS での問い合わせの際に，「その情報が何なのか」を指す重要なタグである.
| レコード名 | 解説 |h
| &color(red){SOA}; | その情報の責任元の情報. Start of Authority. 責任元サーバ名，管理者メールアドレス，データシリアルナンバー, 種々の有効期限長からなる. |
| A | IP Address |
| AAAA | IP Address(IPv6) |
| NS | ネームサーバ |
| CNAME | そのホストの正準名(≒真の名前) |
| MX | そのアドレス宛にメールが来たらどのメールサーバへ送るべきか. 優先順位番号つき. |
| PTR | ホスト名 |
&ref(./warning.png); 見逃しがちだが，上の SOA は「得られた情報がどれくらい信用できるのか」を考える際に重要だ(というのも，得られた情報中に SOA が無い場合はその情報はアヤフヤな可能性がそこそこあるからである).
あと，DNS には時々 "IN" というキーワードが出てくるが，これは Internet という意味なのでまあ気にしなくてよい.
** 正引き [#n93ee15d]
ホスト名から IP Address や他の情報を知るために DNS Server に問い合わせることを正引きという.
正引きできないホストというのはインターネット上では(一応)あってはならない.
** 逆引き [#ae8a1188]
逆に，IP Address からホスト名や他の情報を知ろうとする問い合わせを逆引きという.
ちなみに，逆引きは必ず出来なければいけないはと規定されていない.
つまり，逆引き出来ない IP Address があっても DNS のルール上は問題ない.
ただ，
- ネットワーク上でそれなりにきちんとしたサーバ等はほとんど逆引きをきちんと設定している
- 逆引き出来ないホストに対しては◯◯のサービスをしない，という設定のサーバが結構ある
- 正引きと逆引きの結果が整合しないといけない，というさらに厳しい設定のサーバも結構ある
- 同様のチェックをパスしないと動かないコマンドもある
などなど，逆引きをきちんと設定しないと困る場面もあるので，逆引きできない状況は避けておきたい.
//
//
//
* ユーザとして DNS を使ってみる [#h71c7240]
* ユーザとして DNS を使ってみる [#z86fdc98]
** DNS の状態等を知るツール(1) host [#jda443ea]
サーバの設定以前に，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." が返ってくる.
&ref(./warning.png); host コマンドは律儀にも最後にドットをつけて表示していることに注意!
上記のように，オプション無しだと host コマンドはそっけないが，"-v" オプションをつけるといろいろと情報を出力してくれる.
例えば，
host -v www.osaka-u.ac.jp
とすると, 次のような出力が得られる(結果的に A, AAAA, MX レコードについて尋ねている).
> Trying "www.osaka-u.ac.jp"
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58110
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
> &br;
> ;; QUESTION SECTION:
> ;www.osaka-u.ac.jp. IN A
> &br;
> ;; ANSWER SECTION:
> www.osaka-u.ac.jp. 259200 IN A 133.1.8.18
> &br;
> ;; 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.
> &br;
> ;; ADDITIONAL SECTION:
> sigw.sinet.ad.jp. 36369 IN A 150.100.2.2
> &br;
> Received 127 bytes from 127.0.0.1#53 in 5 ms
> Trying "www.osaka-u.ac.jp"
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33999
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> &br;
> ;; QUESTION SECTION:
> ;www.osaka-u.ac.jp. IN AAAA
> &br;
> ;; AUTHORITY SECTION:
> osaka-u.ac.jp. 10800 IN SOA a.osaka-u.ac.jp. root.odins.osaka-u.ac.jp. 2008121800 10800 1800 3600000 259200
> &br;
> Received 84 bytes from 127.0.0.1#53 in 2 ms
> Trying "www.osaka-u.ac.jp"
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16460
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> &br;
> ;; QUESTION SECTION:
> ;www.osaka-u.ac.jp. IN MX
> &br;
> ;; AUTHORITY SECTION:
> osaka-u.ac.jp. 10800 IN SOA a.osaka-u.ac.jp. root.odins.osaka-u.ac.jp. 2008121800 10800 1800 3600000 259200
> &br;
> Received 84 bytes from 127.0.0.1#53 in 2 ms
ちなみに，DNS 問い合わせ結果表示の中で，"IN" の前にしばしば数ケタの数字が出てくるが，その数字はその情報の残り有効期限(秒単位)，いわば賞味期限である.
他にも，結構多様なオプションがあるので，"man host" として調べておくとよい.
&ref(./notes.png); まずは上と同じようにして host コマンドを使ってみよう.
また，-v オプションの代わりに -a を使ってみよう.
また，適当なホスト名に対して "host -v" で調べた結果を，これまでの知識を元に解釈してみよ.
** DNS の状態等を知るツール(2) dig [#ec4ab47e]
近年では，DNS 問い合わせを手で行うコマンドとしては "dig" が一般的である.
使い方は host に似ているがより細かい((というか細かすぎる))指定が可能だ.
詳しくは "man dig" と "dig -h" で調べてもらうとして，大ざっぱには次のようにつかう.
&ref(./warning.png); "jman dig" とはしないこと! なぜか知らないが，dig に関する日本語マニュアルは相当に古く，オプション等が今のものと全く異なるのだ(全体に日本語マニュアルは古めではあるが，dig は特に古い).
&ref(./warning.png); "jman dig" とはしないこと! なぜか知らないが，dig に関する日本語マニュアルは相当に古く，オプション等が今のものと全く異なるのだ(全体に日本語マニュアルは古めではあるが，dig のそれは特に古い).
&br;
通常の単なる正引きは
dig www.osaka-u.ac.jp
でよい.
単なる逆引きは "-x" オプションを用いて
dig -x 133.1.8.18
とする.
問い合わせに使う DNS server を指定したいときは，@そのサーバ という文字列をオプションとして加える.
例えば，上の結果から www.osaka-u.ac.jp の情報の責任元である DNS Server は a.osaka-u.ac.jp であることが分かるので((必ずわかるとは限らない)),このサーバに何か尋ねてみる.
dig @a.osaka-u.ac.jp www.osaka-u.ac.jp
とすると，
> ; <<>> DiG 9.3.5-P1 <<>> @a.osaka-u.ac.jp www.osaka-u.ac.jp
> ; (1 server found)
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, &color(red){status: NOERROR};, id: 41778
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
> &br;
> ;; QUESTION SECTION:
> ;www.osaka-u.ac.jp. IN A
> &br;
> ;; ANSWER SECTION:
> www.osaka-u.ac.jp. 259200 IN A 133.1.8.18
> &br;
> ;; 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.
> &br;
> ;; 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
> &br;
> ;; Query time: 11 msec
> ;; SERVER: 133.1.192.3#53(133.1.192.3)
> ;; WHEN: Wed Jan 7 17:01:07 2009
> ;; MSG SIZE rcvd: 143
となり，自分が責任者である情報については素直に教えてくれることが分かる(status に注目せよ).
&br;
では，少し調子にのってこのネームサーバに他の問い合わせをしてみよう.
例えば，
dig @a.osaka-u.ac.jp www.yahoo.co.jp
としてみる. すると，
> ; <<>> DiG 9.3.5-P1 <<>> @a.osaka-u.ac.jp www.yahoo.co.jp
> ; (1 server found)
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, &color(red){status: REFUSED};, id: 8576
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> &br;
> ;; QUESTION SECTION:
> ;www.yahoo.co.jp. IN A
> &br;
> ;; Query time: 1 msec
> ;; SERVER: 133.1.192.3#53(133.1.192.3)
> ;; WHEN: Wed Jan 7 17:02:33 2009
> ;; MSG SIZE rcvd: 33
となり("ANSWER SECTION" が無いこと，status が "REFUSED" になっていること，などに注目せよ)，「その情報は僕の管轄じゃないよ」という返答になっていることが分かる.
&br;
ちなみに，DNS Server がどういう内容にどう返答してくれるかは問い合わせ内容とそのサーバの設定と問い合わせる人の関係に依存する.
詳しくは DNS Server の設定を行うと理解できるので，そこまで待とう.
&br;
さて，dig は +trace というオプションをつけると生真面目に自分が再帰的動作を行うので，DNS の仕組みを知るのに都合がよい.
もう少し詳しく書くと，このオプション付きでの dig は，問い合わせ先サーバに「非再帰的に答えてね」と頼む(つまり，問い合わせを丸投げしない).
&ref(./warning.png); 逆に言えば，通常の dig コマンドは質問を最寄りの DNS Serverに「丸投げ」しているだけで，自分は何も苦労していないのだ.
&br;
つまり，+trace つきで dig コマンドを使ったときは，各々のサーバは単に手持ちの知識で最もマシな答えを返してくるので，その解釈とつなぎあわせは dig 自身が行うのである.
例えば，
dig +trace www.osaka-u.ac.jp
とすると，
> ; <<>> DiG 9.3.5-P1 <<>> +trace www.osaka-u.ac.jp
> ;; global options: printcmd
> . 496121 IN NS J.ROOT-SERVERS.NET.
> . 496121 IN NS G.ROOT-SERVERS.NET.
> . 496121 IN NS K.ROOT-SERVERS.NET.
> . 496121 IN NS E.ROOT-SERVERS.NET.
> . 496121 IN NS H.ROOT-SERVERS.NET.
> . 496121 IN NS A.ROOT-SERVERS.NET.
> . 496121 IN NS C.ROOT-SERVERS.NET.
> . 496121 IN NS D.ROOT-SERVERS.NET.
> . 496121 IN NS M.ROOT-SERVERS.NET.
> . 496121 IN NS B.ROOT-SERVERS.NET.
> . 496121 IN NS F.ROOT-SERVERS.NET.
> . 496121 IN NS L.ROOT-SERVERS.NET.
> . 496121 IN NS I.ROOT-SERVERS.NET.
> ;; Received 504 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
> &br;
> 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.
> jp. 172800 IN NS A.DNS.jp.
> jp. 172800 IN NS B.DNS.jp.
> ;; Received 431 bytes from 192.58.128.30#53(J.ROOT-SERVERS.NET) in 64 ms
> &br;
> osaka-u.ac.jp. 86400 IN NS sigw.sinet.ad.jp.
> osaka-u.ac.jp. 86400 IN NS b.osaka-u.ac.jp.
> osaka-u.ac.jp. 86400 IN NS a.osaka-u.ac.jp.
> ;; Received 127 bytes from 204.74.112.245#53(C.DNS.jp) in 126 ms
> &br;
> www.osaka-u.ac.jp. 259200 IN A 133.1.8.18
> osaka-u.ac.jp. 259200 IN NS a.osaka-u.ac.jp.
> osaka-u.ac.jp. 259200 IN NS b.osaka-u.ac.jp.
> osaka-u.ac.jp. 259200 IN NS sigw.sinet.ad.jp.
> ;; Received 159 bytes from 150.100.2.2#53(sigw.sinet.ad.jp) in 15 ms
などのような返答が返ってくる.
これをみると，
+ 自分自身(127.0.0.1)への問い合わせの結果としてまず "."(ルートドメイン)担当の NS
が 13台あることを知る(フルサービスリゾルバと呼ばれるリゾルバは，たいてい最初からこの 13台を知っている).
+ その 13台の中の J.ROOT-SERVICE.NET に "jp." 担当の NS が 7台あると教えてもらって，
+ その 7台の中の C.DNS.JP に "osaka-u.ac.jp." 担当の NS が 3台あると教えてもらって，
+ その 3台の中の sigw.sinet.ad.jp に www.osaka-u.ac.jp. のアドレスを教えてもらった
という流れで検索したことがよく分かる.
ただし，通常は，なるべくネットワーク上を流れる情報が少なくて済むようにキャッシュなどの様々な工夫が用いられているので，このように馬鹿正直に問い合わせが進むわけではない.
*** ルートサーバの重要性とセキュリティ [#k69fe45e]
*** ルートサーバの重要性とセキュリティ [#r2edd16e]
ここで，上に出てきたルートドメイン担当の DNSサーバ(ルートサーバと呼ばれる)について記述しておこう.
このルートサーバは，DNS の総元締であるので，これらがきちんと機能しないとインターネットそのものがきちんと機能しない. &color(red){"The Internet" の「要」};といってよいだろう.
また逆に言えば，インターネットへの攻撃者からみればルートドメインこそが攻撃対象として最も重要なものの一つということになる.
そのため，これまでにも大規模の各種攻撃にたびたびさらされている.
しかし，13台が世界各地に散っていることや使用するソフトウェアを「わざと異なるものにしてある」ことなどから持ち堪えてきたという歴史がある.
&ref(./notes.png); ルートサーバに対するこれまで加えられた攻撃やその経緯について調べておこう. セキュリティを保つためにどうすればよいかという良い学習資料になるはずだ.
&br;
&ref(./warning.png); ちなみに，インターネットを支えるルートドメイン担当サーバ 13((…といってもマシンが13台というわけではなく，外からはそう見えるようになっているというだけで，実態はもっと多い))の管理機関うちわけは，アメリカが 10, 日本が 1, ノルウェーが 1, オランダが 1 である. http://www.root-servers.org/ にリストがあるので，気になる人は見てみよう.
** DNS の状態等を知るツール(3) nslookup [#eec39afa]
dig が広く知られる前はよく使われていたのがこの "nslookup" コマンドである.
ある条件を満たさない問い合わせをそもそも受け付けないことや，実装が中途半端であることなどから「腐っている」と悪口を言われたりしてあまり使われなくなってきているが，対話モードのお気楽さ等を考えると，まあ，そこまでひどいツールではない(^-^)
&ref(./notes.png); "man nslookup" として nslookup のマニュアルを読んでみて，まだ実装されていない("not implemented")機能がどれくらいあるか確認しておこう.
// むしろ通常ユーザにとっての実用上の一番の欠点は，(古めの nslookup では)逆引きが簡単にできないことであろう(最近の nslookup は host コマンドと同じように IP アドレスを渡すだけで逆引きができるようだ.).
&ref(./notes.png); host, dig, nslookup についてマニュアルで調べた後，いくつかのホストについてこれらのコマンドで(正引きで)レコード A, MX について調べてみよ.
また，および得られた IP アドレスを元に逆引きを行ってみよ.
また，自分の携帯のメールアドレスにメールを出す場合，そのメールを受け取るサーバはどこかを調べてみよ.
//
//
//
* DNS サーバを作ってみる(事前知識編) [#zada5062]
さて，DNS server (他には，ネームサーバという名前も良く使われる)ソフトウェアのインストール，設定，稼働にあたり，まずはいくつか注意点を書いておこう.
** DNS server として何を使うか [#f99f5f24]
DNS server ソフトウェアとしては主に BIND (Berkeley Internet Name Daemon) というものが使われる.
もちろん世の中には他のソフトウェアもあるが，BIND の利用率はおよそ 90%あると言われるので，まずは BIND から，という姿勢でよろしかろう.
この BIND は，BSD 由来のソフトウェアであり，FreeBSD ではデフォルトで入っているので，ほぼ最新の FreeBSD を使っているのであればインストール作業は特に不要である.
ただし，後述するセキュリティの問題があるので，その時利用している BIND のバージョンには特に気を使うようにしよう.
あと，混乱しがちであるが，BIND が作るコマンドは named (名前解決のデーモン，とでも思えばよいだろう)という名前であり，マニュアルやディレクトリ名は基本的に "named" という名前が使われるので注意したい.
&ref(./notes.png); 今インストールされている BIND のバージョンを調べておこう. 今の状態だと，具体的には，
named -v
とすればよい.
(FreeBSD 7.0 についてくるのは 9.4.2 であるようだが，念の為に確認しておこう)
** BIND 設定のための資料 [#d1d8a1c4]
なにしろ BIND は古くからあるソフトウェアのため，進化しているとはいってもその設定ファイルの様式は歴史にひきずられた旧態依然とした部分があり，ややわかりにくい.
(とはいっても，DNS を知っていさえすれば設定ファイルを読んで理解できる「気になれる」だけ sendmail の設定ファイルよりは遥かにマシである)
DNS に対する理解ができていない状態で設定ファイルを読むと何がなんだか分からないので，そうした知識取得も兼ねてよい資料に目を通すことを推奨する.
| 名称等 | 備考 |h
| FreeBSD システム管理とチューニング(書籍), page 341--374. | たった30ページで DNS の原理から BIND の設定までをきちんとわかりやすく記述したありがたい資料. BIND 8 についての記述なので，最後の方の一部の記述が古くなってしまっている点のみが欠点と言えば欠点. |
| FreeBSD ビギナーズバイブル(改訂第二版)(書籍), page 543--565. | わかりにくい設定の代表格(^-^)である逆引き委譲の仕組みについて詳しく書かれていてありがたい. |
| BIND 9 による DNS サーバ構築(書籍) | とてもわかりやすく書かれていてよい. 本気でお勧め. ただ，逆引きについては「割愛」されているのがとてもとても残念(こんなに分かり易く書ける著者には是非書いて欲しかった) |
| DNS & BIND (書籍) | 定番中の定番. インターネットに繋がって実際にネームサーバとなるサーバを扱うならば買っておかないといけないだろう.ただ，ぱっと読んですぐ理解できるとなどとは期待してはいけない. |
** DNS server とセキュリティ [#i47c1234]
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 より上には出られない.
&ref(./notes.png); DNS サーバの提供するネットワーク情報を「偽装」することで成功するネットワーク攻撃について調べてみよ.
/etc/namedb というディレクトリが実際にはどこにあるか調べよ.
* レポート [#l9875a9f]
途中で「調べよ」と指示された事項について調査を行い，報告せよ.
また，本日行った作業について報告せよ.
もちろん各自の
+ 所属(学部，学科)
+ 学籍番号
+ 学年
+ 氏名
+ 日時
+ 肝心のレポート内容(得た知見，作業について気づいたこと等)
を書くのを忘れないように.
* about Icons [#p90706c9]
Some icons in this page are downloadable at [[ICONFINDER:http://www.iconfinder.net/]].
The "note" icon &ref(./notes.png); designed by [[Marco Martin:http://www.notmart.org/]] is distributed with the LGPL licence
and the "warning" icon &ref(./warning.png); designed by [[Alexandre Moore:http://nuovext.pwsp.net/]] with the GPL licence.
Thank you Marco and Alexandre!
// &ref(./notes.png);
// &ref(./warning.png);
