13.ドメインとDNSの詳細
13-1. ドメインとDNSの基本
(1) はじめにドメインとは '96
* ドメイン名の基本
[ ドメイン名の意味 ]
閉じたネットワ−ク、例えばインタ−ネットに接続しない社内だけのネットワ−クの中で
は、ドメイン名はなんでもいい。ただの a でも B でも henohenomohe でも構わない。普
通ドメイン名は abc.co.jp というような名称になっているが、 これは1つの名前に過ぎ
ない。それにネットワ−クのセグメントがたくさんあるネットワ−クでも、別に1つのド
メイン名で表わしても構わない。
ドメイン名 | IPアドレス
--------------|--------------
hostA.aa.net | 192.2.100.1 別にこんなんでもいい。
hostB.aa.net | 162.1.200.7
hostC.aa.net | 202.9.300.3
ちなみにIPアドレスの番号についても説明しておく。 例えば 199.2.100.3 というIP
アドレス。これは階層構造を表わしているのでも何でもない。ネットワ−クの識別番号と
して 199.2.100.0 があって、その 3 という番号が、そのホストの識別番号と言うことだ
けである。3番目というような意味ではない。
[ ドメイン名の階層 ]
実はドメイン名は、論理的な階層構造をとることができる。コンピュ−タの台数が多くな
ってくると、1つのネットワ−ク名+ホスト名では管理に無理が生じてくる。部署ごとと
か建屋のフロア−毎に、ネットワ−ク名を分けたいというのは、自然なことである。この
考え方を世界中のネットワ−クに適用したのがインタ−ネットである。部署ごととか建屋
のフロア−毎にというのが、日本を表わす jp、 企業を表わす co というような区分けに
なっている。
建物 全体のネットワ−ク名は net、それぞれの階のネ
------------ ットワ−ク名は f1, f2、そしてホスト名がくる。
| 2階 |
| hostY | hostY.f2.net /etc/hosts
|----------| --------------------------
| 1階 | |192.10.10.1 hostY.f2.net
| hostX | hostX.f1.net |192.10.10.2 hostX.f1.net
------------
[ ドメイン名の管理 ]
上の例で2つのホストしかなければ、それぞれのホストの /etc/hosts ファイルにお互い
のホスト名とIPアドレスを書くだけのことである。しかし、ホストの数が何百台、何千
台にもなったら大変である。ホスト全部の名前を書いた hosts ファイルを、 全てのホス
トにコピ−しなければならない。インタ−ネットの初期の時期には、実際このやり方がと
られた。接続するコンピュ−タの数が膨大になり、 考え出されたのが DNS( Domain Name
System )という仕組みである。DNS はホストの名前とそのIPアドレスのテ−ブルをうま
く分散管理する。
f2.net ドメイン f1.net ドメイン
------------------ -----------------
| 管理ホスト名 | | 管理ホスト名 | xxx.f2.net のホスト名は
| | | | f2.net の管理プログラム
| hostA.f2.net |-------| hostX.f1.net | に聞いてくれ。
| hostB.f2.net | | hostY.f1.net |
------------------ -----------------
* ドメインの階層構造
ドメインの階層構造と、物理的なネットワ−クの構成とは対応しない。ドメインの階層構
造というのは、論理的な階層構造に過ぎないことに注意したい。
[ 例1 ]
root
A □ A.b.a * ドメイン階層
| |
--------------------- b.a ----------------------- a
|B.b.a | |
B □ → | |
|B.a -------- b.a ------- c.a
------------------ a
|C.a
C □ a はドメイン、b.a は a のサブドメインを
|C.c.a 意味する。 B.a は a ドメインの B という
--------------- c.a マシン名を意味する。
[ 例2 ] 1本のネットワ−ク・セグメントで2つのドメインに分かれている。
root
A.a B.a C.b A.a B.a ------------- C.b
| | | → | | | | |
a --------------|------- b ------------- a ---------- b
[ 例3 ] 1本のネットワ−ク・セグメントで主ドメインとサブドメインに分かれている。
root
A.a B.a C.b.a * A.a B.a
| | | → | | |
a --------------|------- b.a -------------------- a
|
| C.b.a
| |
--------------- b.a
[ 例4 ] 1つのドメインが2本のネットワ−ク・セグメントに分かれている。
root
A.a B.a C.b A.a B.a ------------- C.a
| | | → | | | | |
---------------------- a ------------- a ----------- a
192.10.10.1 192.10.10.2
* DNS 動作の仕組み
DNS( Domain Name System )は、TCP/IP ネットワ−クでホストを名前で認識するための仕
組みである。TCP/IP ネットワ−クと言うのは、 つまりインタ−ネットの仕組みでもある。
DNS の一般的な実装は BIND( Berkeley Internet Name Domain )を用いる。アメリカのバ
−クレ−大学で作成されたものである。EWSでのデ−モン、すなわち実装プログラムは
named または in.named である。以下とりあえず named として話しを進めていく。 たい
がいEWSには最初から named プログラムは入っている。 新しいバ−ジョンをインスト
−ルしたいような場合は、バ−クレ−大学のサイトなどから取って来ることになる。以下
は BIND 4.x を実装した named についてである。
named サ−バの設定は /etc/named.xxx という一連の制御ファイルを作成する必要がある。
具体的には /etc/named.boot, named.ca, named.hosts, named.rev, named.local ファイ
ルである。そのクライアントはEWSでは /etc/resolv.conf ファイルを設定することで
ホスト名の名前解決ができるようになる。/etc/resolv.conf には named サ−バのIPア
ドレスを1つまたは複数列挙する。 1個の DNS が管理するホスト名全体をゾ−ンという。
正確に言えば1つの named.hosts に記述した、 ホスト名とIPアドレスの対応情報の集
合を示す。インタ−ネット全体では、このゾ−ンの集合としてホスト名が認識されるよう
になっているのである。
* ネ−ムサ−バ named の働き方
あるドメインに属するホスト名を管理する、大元のサ−バを1次ネ−ムサ−バという。そ
の管理デ−タのコピ−を持つサ−バを2次ネ−ムサ−バという。これらのサ−バは別々の
ホストで稼働させ、named デ−モンがその役割を担う。管理デ−タのコピ−は、2次側が
named-xfer というプログラムでもって1次側から取ってくる。 2次ネ−ムサ−バは1次
側の named デ−モンが止まったり、 そのホストが止まったりした場合の予備としての存
在である。EWSでは /etc/resolv.conf ファイルの最初に、1次ネ−ムサ−バのIPア
ドレス、その次に2次ネ−ムサ−バのIPアドレスを記載して指定する。
1次ネ−ムサ−バ : primary name server ともいう。
2次ネ−ムサ−バ : secondary name server ともいう。
ネ−ムサ−バ
----------- ----------- -----------
| hostA.a | | hostB.a | | hostC.a |
----------- ----------- -----------
| .1 | .2 | .3
---------------------------------------------------- 100.1.0
ドメイン a
% ping hostC.a
↓
/etc/resolv.conf → named
----------------
|100.1.2 ↓
named.hosts
ping 100.1.3 ← --------------
|hostC 100.1.3
(3) 2次ネ−ムサ−バの基本
* 基本
ドメインのホスト名を管理するのに、1ヵ所だけでは心もとない。それで管理デ−タのコ
ピ−を他でも持ってもらう。この情報を named.boot に書くようになっている。2次ネ−
ムサ−バを起動した時に、 1次ネ−ムサ−バから File の内容を File' と言うファイル
名で、2次ネ−ムサ−バがコピ−する。その後は一定時間毎に、2次ネ−ムサ−バが1次
側を見て、変化があればコピ−してくる。 ここでの File は DNS の正引き情報が記述さ
れたファイルである。ファイル名は named.hosts のよう名前で、何でも構わない。File'
はそのコピ−ファイルで、同様ファイル名は何でもいい。他、それぞれの named.boot に
は DNS の逆引き情報のファイルも記述する。こちらは named.rev といったファイル名で
ある。1次の named が落ちていて、2次の named を再起動する場合、 これら File' の
記述により DNS の情報を初期化することになる。
named.boot named.boot
---------------- -----------------------
|primary a File |secondary a IP1 File'
1次ネ−ムサ−バ 2次ネ−ムサ−バ
------- ------- IP1 は1次ネ−ムサ−バのホスト
|hostA| File |hostB| File' のIPアドレス。以下の説明のた
------- ------- め 192.9.200.1 としておく。 ド
| IP1(192.9.200.1) | メインは、 ここでの説明は a と
------------ ---------- したが、以下 nix.co.jp とする。
ドメイン a( nix.co.jp )
* 種類
named.boot
--------------------------------------------------- 自ドメインの正引き情報
|primary nix.co.jp named.hosts の大元を管理してます。
named.boot
--------------------------------------------------- 他のドメインのコピ−を
|secondary nix.co.jp 192.9.200.1 named.hosts.sec 持ってます。
named.boot
--------------------------------------------------- 自ドメインと他のドメイ
|primary nix.co.jp named.hosts ンの情報を持ってます。
|secondary nix.co.jp 192.9.200.1 named.hosts.sec
named.boot
--------------------------------------------------- 自ドメインの逆引き情報
|primary 200.9.192.in-addr.arpa named.rev を持つ場合。
* インタ−ネットでの設定
インタ−ネットに接続した場合、どのようにネ−ムサ−バが記述されるのか示した。2次
ネ−ムサ−バは、接続プロバイダになってもらうことにし、henomohe.or.jp とする。 イ
ンタ−ネットから nix.co.jp ドメインのホストへアクセスするには、先ず hostZ の DNS
を見てIPアドレスを検索する。 もしこの DNS が落ちていたりしたら hostY の DNS を
見ることになる。 hostY の DNS には named.hosts と named.rev のコピ−を持ってもら
う。かつての DNS の仕様では named.rev は無くても構わなかった。しかし最近では外部
のホストにアクセスする際、 認証のため相手が named.rev を見ることが多くなっている。
直ぐに電話を受けるのでなく、掛け直して本当に相手かどうかチェックするようなもので
ある。
* root
|
-----------------------------------
| -------
| |hostX| << JPNIC のネ−ムサ−バに nix.co.jp を登録してもらう。
| ------- 逆引きの 128.241.202.in-addr.arpaも登録してもらう。
| |
----------------------------------- jp
| |
| ------- | -------
| |hostY| DNS2次 | |hostZ| DNS1次
| ------- | -------
| | | | .1
------------- ---------------- 202.241.128.0
henomohe.or.jp nix.co.jp 自サイトのドメイン
[ hostX での DNS の記述 ] JPNIC のネ−ムサ−バ
/etc/named.hosts
-------------------------------------------
|@ IN SOA ....
| |
|nix.co.jp. IN NS hostZ.nix.co.jp. << 1次ネ−ムサ−バの記述。
| IN NS hostY.henomohe.or.jp. << 2次ネ−ムサ−バの記述。
|hostZ.nix.co.jp. IN A 202.241.128.1
/etc/named.rev
-------------------------------------------
|@ IN SOA ....
| |
|128.241.202.in-addr.arpa. IN NS hostZ.nix.co.jp. << 逆引き情報の記述。
[ hostY での DNS の記述 ]
/etc/named.boot
-------------------------------------------
| | ここは henomohe.or.jp 自体 別にどんなファイル名でもいい。
| | の named.boot の設定を記述 ディレクトリ指定を入れてもいい。
| ↓
|secondary nix.co.jp 202.241.128.1 named.hosts.sec
|secondary 128.241.202.in-addr.arpa 202.241.128.1 /bak/named.rev.sec
[ hostZ での DNS の記述 ]
/etc/named.boot
-------------------------------------------------------
|cache . /etc/named.ca
|primary nix.co.jp /etc/named.hosts
|primary 128.241.202.in-addr.arpa /etc/named.rev
|primary 0.0.127.in-addr.arpa /etc/named.local
nix.co.jp ドメインのホスト名の情報と、202.241.128.0 ネットワ−クのIPアドレ
スの情報をこの DNS は管理している。上位のドメイン、つまり co.jp ドメインから
管理の権限を委譲されているという。nix.co.jp ドメイン、202.241.128.0 IPアド
レスの Authorized されたゾ−ン情報を持っているといった言い方をする。named.ca
はインタ−ネットのル−トキャッシュのファイルを使う。
* ゾ−ン転送の制限
1次ネ−ムサ−バの named.boot ファイルにおいて、2次ネ−ムサ−バへのゾ−ン転送を
制限するオプションが、BIND 4.9.7 で追加されたようである。 man マニュアルを見ると、
そのようなことが控えめに書かれてあった。他にも limit とか check-names とか見たこ
とないオプションも書かれてあった。しかし BIND 4.9.7 は BIND 4 系列では最後であり、
もう BIND 4 系列 の named の使用はやめ、BIND 8 系列を使うべきであろう。
named.boot
-------------------------------------------------------
|xfrnets 2次ネ−ムサ−バのIPアドレス&ネットマスク
|;xfrnets 127.0.0.1&255.255.255.255 どこからもダメ
注.1999年4月 JPNIC は管理するDNSのゾ−ン転送の制限を実施するとアナウンス
した。JPNICはそれ独自でDNSを管理しているのだから、他に2次ネ−ムサ−バを立
ててもらうことはないし、第三者にゾ−ン情報を見てもらう必要もない。 このことは
JPNIC のネ−ムサ−バに限らず、 我々が管理する末端のネ−ムサ−バでも同じことが
いえる。インタ−ネットの危険性から身を守るためには、 必要最低限の情報しか外に
出さないようにした方が無難である。
(3) DNS ドメインの階層構造 '96
* ドメインの階層構造の基本
ドメインが階層構造をとり、サブドメインをもつ場合、親ドメインはサブドメインのホス
ト名の検索の窓口になる。親ドメインはサブドメインについては、どこそこに聞いてくれ
という情報をもたなければならない。これは named.hosts に書くことになっている。
hostA の named.hosts
-------------------------
|a. IN NS hostA.a. << 自ドメインの1次ネ−ムサ−バ。
|b.a. IN NS hostB.b.a. << サブドメインの1次ネ−ムサ−バ。
------- named.boot
|hostA| a の1次 --------------------------
------- |primary a named.hosts
|
--------------------- a
| ------- named.boot
| |hostB| b.a の1次 --------------------------
| ------- |primary b.a named.hosts
| |
------------------- b.a
* 2次ネ−ムサ−バがある場合
hostB の named.hosts
---------------------------------------
|b.a. IN NS hostB.b.a. << 自ドメインの1次ネ−ムサ−バ
| IN NS hostA.a. << 自ドメインの2次ネ−ムサ−バ
|
|c.b.a. IN NS hostC.c.b.a. << 下位ドメインの1次ネ−ムサ−バ
| IN NS hostB.b.a. << 下位ドメインの2次ネ−ムサ−バ
------- named.boot a の1次は他にあるとする
|hostA| b.a の2次 ---------------------------------
------- |secondary b.a named.hosts.sec
|
--------------------- a
| named.boot
| ------- ---------------------------------
| |hostB| b.a の1次 |primary b.a named.hosts
| ------- c.b.a の2次 |secondary c.b.a named.hosts.sec
| |
------------------- b.a
| named.boot
| ------- ---------------------------------
| |hostC| c.b.a の1次 |primary c.b.a named.hosts
| -------
| |
----------------- c.b.a
* ホスト名検索の例

Fig. d21
* サブドメインと主ドメインの関係
ホストA、Bでは自ドメインのみ管理する DNS が働いているとする。b.a のサブドメイ
ンが a ドメインのホストを認識するためには、ホストBでどのように DNS を設定すれば
いいか。
------ ここでは b.a を認識できるよう
| A | named.hosts に NS B を入れて
------ あるものとする。
| ====================================
--------------------- a ファイアウォ−ルやセキュリティの関係
| ------ から色々な方法がとられることになる。
| | B | ====================================
| ------
| |
------------------- b.a
1. ル−トキャッシュを a ドメインにする。<< DNS の設計思想からすればコレが妥当。
2. named.hosts に NS A を入れる。
3. /etc/resolv.conf に nameserver A を入れる。
4. Aの2次ネ−ムサ−バになる。
5. Aを forward 指定する。
(4) DNS 管理ゾ−ンの範囲
* 単一ドメインでゾ−ンの管理を委譲しない場合の基本
named A ■ B □ ホストAの DNS がホスト
|.1 |.2 A,B,C,Dのゾ−ン情報
------------------------- 192.9.200.0 nix.co.jp を管理する。
|
□ C □ D □
| |3. |.4
------------------------- 192.9.201.0 nix.co.jp
/etc/named.boot
------------------------------------------------------
|cache . /etc/named.ca
|primary nix.co.jp /etc/named.hosts
|primary 200.9.192.in-addr.arp /etc/named.rev0
|primary 201.9.192.in-addr.arp /etc/named.rev1
|primary 127.in-addr.arpa /etc/named.local
/etc/named.hosts
--------------------------------------------------------------
|@ IN SOA hostA.nix.co.jp. katou.hostA.nix.co.jp. (
| 1 3600 300 3600000 360000 )
| IN NS hostA.nix.co.jp.
|localhost. IN A 127.0.0.1
|hostA IN A 192.9.200.1
|hostB IN A 192.9.200.2
|hostC IN A 192.9.201.3
|hostD IN A 192.9.201.4
/etc/named.rev0 /etc/named.rev1
------------------------------------- -------------------------------------
|@ のところ上に同じ |@ のところ上に同じ
| IN NS hostA.nix.co.jp. | IN NS hostA.nix.co.jp.
|1 IN PTR hostA.nix.co.jp. |3 IN PTR hostC.nix.co.jp.
|2 IN PTR hostB.nix.co.jp. |4 IN PTR hostD.nix.co.jp.
/etc/named.local
-------------------------------------
|@ のところ上に同じ
| IN NS hostA.nix.co.jp.
|$ORIGIN 127.in-addr.arpa.
|1.0.0 IN PTR localhost.nix.co.jp.
/etc/named.ca ロ−カルのネットワ−ク内でのみ使えるル−トのドメイン情報
--------------------------------------------------
|. 9999999 IN NS hostA.nix.co.jp. ドメインのル−トが nix.co.jp
|hostA.nix.co.jp. 9999999 IN A 192.9.200.1 ということである。
[ インタ−ネットと接続する場合の上位ドメインでの登録 ]
/etc/named.hosts /etc/named.ca はインタ−ネット用の
----------------------------------------- ル−トキャッシュ・ファイルを使う。
|nix.co.jp. IN NS hostA.nix.co.jp.
|hostA.nix.co.jp. IN A 192.9.200.1
/etc/named.rev
------------------------------------------------
|200.9.192.in-addr.arpa IN NS hostA.nix.co.jp.
|201.9.192.in-addr.arpa IN NS hostA.nix.co.jp.
* サブドメインでゾ−ンの管理を委譲しない場合
A ■ B □
|.1 |.2
------------------------- 192.9.200.0 nix.co.jp
|
□ C □ D □
| |3. |.4
------------------------- 192.9.201.0 aaa.nix.co.jp
/etc/named.boot
------------------------------------------------------
|cache . /etc/named.ca
|primary nix.co.jp /etc/named.hosts
|primary 200.9.192.in-addr.arp /etc/named.rev
/etc/named.hosts
--------------------------------------------------------------
|@ IN SOA hostA.nix.co.jp. katou.hostA.nix.co.jp. ( ..
| IN NS hostA.nix.co.jp.
|hostA IN A 192.9.200.1
|hostB IN A 192.9.200.2
|hostC.aaa IN A 192.9.201.3
|hostD.aaa IN A 192.9.201.4
/etc/named.rev
-----------------------------------------
|@ のところ上に同じ
| IN NS hostA.nix.co.jp.
|1 IN PTR hostA.nix.co.jp.
|2 IN PTR hostB.nix.co.jp.
|
|$ORIGIN 201.9.192.in-addr.arpa. << こういう記述の仕方もできる。しか
|3 IN PTR hostC.aaa.nix.co.jp. し管理するゾ−ンの範囲が分かりに
|4 IN PTR hostD.aaa.nix.co.jp. くくなる。あまりよろしくない。
* サブドメインでゾ−ンの管理を委譲する場合
A ■ B □
|.1 |.2
------------------------- 192.9.200.0 nix.co.jp
|
□ C ■ D □
| |.3 |.4
------------------------- 192.9.201.0 bbb.nix.co.jp
hostA /etc/named.boot
------------------------------------------------------
|cache . /etc/named.ca
|primary nix.co.jp /etc/named.hosts
|primary 200.9.192.in-addr.arp /etc/named.rev
hostA /etc/named.hosts
-----------------------------------------------------------------
|@ IN SOA hostA.nix.co.jp. katou.hostA.nix.co.jp. ( ..
|nix.co.jp. IN NS hostA.nix.co.jp.
|hostA.nix.co.jp. IN A 192.9.200.1
|hostB.nix.co.jp. IN A 192.9.200.2
|
|bbb.nix.co.jp. IN NS hostC.bbb.nix.co.jp.
|hostC.bbb.nix.co.jp. IN A 192.9.201.3
hostA /etc/named.rev
-------------------------------------
|@ のところ上に同じ
| IN NS hostA.nix.co.jp.
|1 IN PTR hostA.nix.co.jp.
|2 IN PTR hostB.nix.co.jp.
hostB /etc/named.boot
------------------------------------------------------
|cache . /etc/named.ca
|primary bbb.nix.co.jp /etc/named.hosts
|primary 201.9.192.in-addr.arp /etc/named.rev
hostB /etc/named.hosts
-------------------------------------------------------------------------
|@ IN SOA hostC.bbb.nix.co.jp. katou.hostC.bbb.nix.co.jp. ( ..
|bbb.nix.co.jp. IN NS hostC.bbb.nix.co.jp.
|hostC.bbb.nix.co.jp. IN A 192.9.201.3
|hostD.bbb.nix.co.jp. IN A 192.9.201.4
hostB /etc/named.rev
-----------------------------------------
|@ のところ上に同じ
| IN NS hostC.bbb.nix.co.jp.
|3 IN PTR hostC.bbb.nix.co.jp.
|4 IN PTR hostD.bbb.nix.co.jp.
[ インタ−ネットと接続する場合の上位ドメインでの登録 ]
/etc/named.hosts
-----------------------------------------
|nix.co.jp. IN NS hostA.nix.co.jp. << bbb.nix.co.jp のゾ−ン情報はここ
|hostA.nix.co.jp. IN A 192.9.200.1 をたどって検索されることになる。
/etc/named.rev
---------------------------------------------------
|200.9.192.in-addr.arpa IN NS hostA.nix.co.jp.
|201.9.192.in-addr.arpa IN NS hostC.bbb.nix.co.jp.
(5) ネ−ムサ−バの適切な設定へ `24/04
* ネ−ムサ−バのプログラムは何を使えばいいか
BIND であれば、BIND 4.x はもう使わないこと。http://www.isc.org/ サイトで最新バ−
ジョンを確認して、基本的には最新のを使うようにすること。古いのは DoS攻撃のセキュ
リティ・ホ−ルがあるとか問題がある。 sendmail に較べればセキュリティ・ホ−ルの発
見は少ないが、BIND の実装も決して安全とはいえない。現時点では BIND 8.x系列であれ
ば、2004/01/26 リリ−スの BIND 8.4.4。BIND 8.x 系列であれば、2003/10/23 リリ−ス
の BIND 9.2.3 が最新である。2004/04/20 BIND 9.3 β版リリ−ス。
BIND でなく djbdns を使うことをそろそろ考えてもいい。qmail や ucspi-tcp を作った
D.J.Bernstein 氏が開発したプログラムである。安全、確実、高速、簡潔、設定も簡単と
いうことである。http://djbdns.qmail.jp/。djbdns の前身 dnscache は1999年12
月にリリ−スされている。それ以来セキュリティ・ホ−ルは1つも見つかってないのでな
いか。国内では前野年紀氏が窓口となっている。 BIND に較べプログラム・コ−ドは格段
に短く、dnscache には嘘の情報を送り込みにくくしている。
djbdns ではコンテンツ(DNS)サ−バとプロキシ(キャッシュ)サ−バがあり、分離している
ことが重要であると述べている。tinydns は自分が管理しているゾ−ンの情報だけを外部
からの問い合わせに答える。キャッシュしたり、再帰検索することはない。クライアント
は dnscache に他ドメインのホスト名の検索を依頼する。 root DNS に遡って検索するた
め再帰検索を行う。そして解決したIPアドレスをキャッシュする。
A.2からC.2にアクセス root DNS B.1からA.1にアクセス ※ BINDでもこのよう
←――――― ■ ←――――― に分離はできるが、
| / | | | DNS 相当のネ−ム
------------↓------/--------↓----------|---------------- サ−バにもキャッ
| | | シュしてしまうの
C.1 C.2 | ■ □ ← A.2 | ■ A.1 □ ← B.1 B.2 | でないか。再帰検
| | | | | | | | | | | | | 索はrecursion no
--------------- -------------------- -------------------- にすれば、再帰検
DNS Cache DNS(tinydns) Cache(dnscache) 索しなくはできる。
* DNS健全化タスクフォ−ス
http://www.nic.ad.jp/ja/dnsqc/、"ネ−ムサ−バの適切な設定に向けて"。DNSに関す
る知識が不十分なため、正しくDNSが設定されないまま運用されている。このような状
況を改善するため、現在の状況を観測し分析する。そして分析した結果を公表し改善を求
める。このようなことは民間レベルではできないことであり、公益法人である JPNICが行
うことと判断したとある。2000年5月に JPNIC は WIDE プロジェクト、それに JPRS
と共同して "DNS健全化タスクフォ−ス DNSQC-TF"を設立し、活動を始めた。2003
年の活動報告では、国内のDNSサ−バを調べたところ、3割以上でおかしな設定をして
たり、セキュリティに問題のあるバ−ジョンを使っていたりしている。2003年9月か
らは指定事業者へその情報を提供しているという。次はチェックした項目の幾つかである。
・MX に CNAME、NS に CNAME は規定違反。
・SOA のホスト名にアンダ−ラインが含まれている。
・Lame Delegation、不十分な委譲をしてないか。
DNS設定のチェックサイトというのがある。「UNIX MAGAZINE」`22/09, P.88〜99, "こ
けつまろびつUNIX 27 DNSチェックリスト" にあったのは http://www.dnsreport.com/、
それに http://www.squish.net/dnscheck/。もう1つ確か JPRS の "DNS関連技術情報
のサイト" に出ていたので http://www.zonecheck.fr/。http://dns.qmail.jp/ の「DN
Sの基礎知識」も参照されたい。正しいDNSの制御ファイルを記述しないと、その内に
インタ−ネットが機能しなくなってしまうかも知れない。可能性はだいぶあるような気が。
* 正しい制御ファイルの書き方
[その1] 正引きファイル
----------------------------------
|@ IN NS ns1.nix.co.jj. <<
| IN NS ns2.nix.co.jj. << CNAME 以外のレコ−ドは無視される。NS レコ
| IN CNAME hostA.nix.co.jj. −ドの2つは無いことになってしまう。
|hostA IN A 192.168.1.1
↓ こうすること
----------------------------------
|@ IN NS ns1.nix.co.jj.
| IN NS ns2.nix.co.jj.
| IN A 192.168.1.1
|hostA IN A 192.168.1.1
[その2] 正引きファイル
----------------------------------
|@ IN NS ns1.nix.co.jj.
|ns1 IN CAME hostA << CNAME を指す NS レコ−ドは無視される。
|hostA IN A 192.168.1.1
----------------------------------
|@ IN MX 10 mbox.nix.co.jj.
|mbox IN CAME hostA << 間違いではないが、相手は検索するのに二度
|hostA IN A 192.168.1.1 手間になる。
[その3] 正引きファイル
----------------------------------
|www IN A 192.168.1.5 << この記述は問題ない。同じマシンで WWW サ−
|ftp IN A 192.168.1.5 バと FTP とメ−ルサ−バのサ−ビスをしてい
|mail IN A 192.168.1.5 る状況。
逆引きファイル
---------------------------------- << こっちは複数の指定はダメ、1個だけ。 同じ
|5 IN PTR www.nix.co.jj. マシンに幾つものホスト名は、 記述してはい
|;5 IN PTR ftp.nix.co.jj. けないことになっている。nslookup で見ると
|;5 IN PTR mail.nix.co.jj. 3つ記述すれば、3つ出ては来るが。
* その3で気付いたことなど
正引きファイル 逆引きファイル
---------------------------------- ----------------------------------
|@ IN SOA ns0.nix.co.jj. ... |@ IN SOA ns0.nix.co.jj. ...
| IN NS ns0.nix.co.jj. | IN NS ns0.nix.co.jj.
| |
| IN MX 10 mail.nix.co.jj. |2 IN PTR www.nix.co.jj.
|ns0 IN A 192.168.1.2 |3 IN PTR mail.nix.co.jj.
|www IN A 192.168.1.2 |1 IN PTR taro.nix.co.jj.
|ftp IN A 192.168.1.2
|mail IN A 192.168.1.3
|taro IN A 192.168.1.1
ftp.nix.co.jj の逆引きレコ−ドがないことに注
named 意。これが問題になることは先ずない。逆引きし
: --------- ------ て正引きしてIPアドレスが一致をチェックする
: |WWW,FTP| |Mail| のはクライアントに対してのことである。サ−バ
Router □ --------- ------ に対するチェックは現在のところ無いのでないか。
| | | もし ftp.nix.co.jjに対してあったとしても、逆
-----------*--------*--------*--- 引きで 192.168.1.2 のホスト名をwww.nix.co.jj
| .1 .2 .3 と検索、更にこれを正引きして 192.168.1.2とな
NAT ------- る。このDNSで必ず記載しておく必要のある逆
| | ファイアウォ−ル 引きレコ−ドは、このドメインから外へアクセス
------- する代表としてのクライアント 192.168.1.1であ
| る。このIPアドレスが信用に足るものか相手先
----------------------------- が調べられるように用意しておくのである。
* BIND 8.x, 9.x でのDNS設定
JPRS の http://jprs.jp/tech/、"DNS関連技術情報のサイト"を見られたい。その中の
「DNSサ−バ−の安全な設定」"Internet Week 2003/DNS DAY"、PDFファイル、17ペ−ジ。
「DNS再入門」"Internet Week 2002/DNS DAY"、PDFファイル、41ペ−ジ。要点である。
DNS制御ファイルの SOA の例
-----------------------------------------------------
|$ORIGIN example.jp.
|$TTL 86400
|@ IN SOA ns1.example.jp. hostmaster.example.jp. (
| 2002121901 ; Serial � \
| 86400 ; Refresh |これらはスレ−ブからマスタ−への
| 21600 ; Retry |ゾ−ン転送の要求に関わる変数の値。
| 24192000 ; Expire /�
| 1200 ; SOA TTL ( Negative Cache )
| )
Serial --- BIND では YYYYMMDDnn が推奨されている( RFC1912 )。
Refresh -- 86400 秒は24時間。どうも1時間とか数時間程度が望ましいらしい。
Retry ---- Refresh の数分の1の値にする。あまり気にしなくてもいい。
Expire --- Refresh より大きくすること。通常は2〜4週間( RFC1912 )。
SOA TTL -- 数10分程度、RFC2308 のサンプルは20分(1200)。存在しない
ようなホスト名をアクセスした場合、それを記憶しておく時間。
$TTL ----- 1日から3日、RFC2308 のサンプルは1日(86400)。BIND 4.x 代
での Minimum TTL( SOA TTL ) がこの値である。
かつて SOA TTL の値は1〜5日が適切とされてきた( RFC1912 )。 1日は 86400 である。
BIND 8.2 以降、TTL の意味が変わり、また $TTL が新設された。BIND 8.x では $TTL が
記述されてないと SOA TTL の値が $TTL として取られる。BIND 9 では $TTL は記述して
ないと、named 起動時にエラ−が出るようになっている。
※ 因み djbdns では Serial値は、ファイルのタイムスタンプから自動生成されるように
なっている。それに djbdns はゾ−ン転送機構は使わないので Refresh 値は関係ない。
※ BIND 8 からできた Notify 機構がデフォルトで働くようになっている。Refresh 時間
を待たずにゾ−ン転送が行われる。ただし Serial 値はこの場合でも関係する。
* 参考文献など `23/11
インタ−ネットに関わって以来、なぜか年末になると DNS の設定をいじったり、 勉強し
たりしている。それだけ奥が深いということだろう。本章は日付の通り1996年当時に
書いた。まだインタ−ネット接続する前のことだった。当時、小生にとっては唯一の参考
書ともいうべき Apollo DOMAIN/OS のマニュアルを見て勉強したのだった。しかしだいぶ
プリントミスも多く理解するのは難しかった。「UNIX MAGAZINE」 も継続購読していたの
でめぼしい記事を拾った。1995年6月号の記事なんか嘗めるようにして読んだもので
ある。それがもう溢れんばかりに情報はある。本も一杯発行された。雑誌のめぼしい記事
は目につく度に書き留めていた。「よい子のイントラネット」読者のため、何かの参考に
でもなればと思い、列挙しておくことにする。しかし実際、DNS 理解の早道は、自分でミ
ニ・インタ−ネットを作って動作を確かめてみることである。2台マシンがあればできる、
「DOMAIN TCP/IP 構成方法と管理の手引き」 日本アポロコンピュ−タ作成。
> "Configuring and Managing TCP/IP" 英語版の日本語版 1986/03 第1版。
「UNIX MAGAZINE」'95/06, P.44〜53, "インタ−ネットの利用と仕組み、ネ−ムサ−バの
> 設置"。吉村伸、MX レコ−ド、ファイアウォ−ル用のマ−ジサ−バ、3系列のサ−バ。
「UNIX MAGAZINE」'97/04, P.29〜37, "UNIX知恵袋 ネ−ムサ−バ−(2)"。
> BIND 4 系列での named 制御ファイルの書き方が詳しい。
「UNIX MAGAZINE」'98/10, P.16〜23, "ファイアウォ−ルの作り方"。
> DNSの簡単な説明、偽情報のキャッシュ、ネ−ムサ−バへの攻撃、ゾ−ン転送の悪用。
「UNIX MAGAZINE」'98/11, P.30〜41, "ファイアウォ−ルの作り方"。
> BIND 4 系列での解説。内部の DNS 情報を公開/非公開にする場合。
「Software Design」'99/02, P.81〜, "Linux で BIND8.1.2 を使ってみよう"。
> http://www.d1.dion.ne.jp/~bash に掲載した記事がある。
「UNIX MAGAZINE」'99/03、P.93〜96、"DAEMONS & DRAGONS BINDバ−ジョン8"。
> William LeFebvre from UNIX REVIEW。こんな記事もあった。
「Software Design」'99/06, P.105〜134,"第2特集:常時接続時代到来DNSの基礎知識"。
> DNSの仕組み、Linux で BIND-8.2.1、クラスC、Dynamic DNS と IPv6。
「UNIX MAGAZINE」`02/11, P.84〜90, "DNSの拡張、IPアドレスの自動設定"。
> BIND 8 の Notify プロトコルの仕組み。マスタ−サ−バ−とスレ−ブサ−バ−。
「UNIX MAGAZINE」`21/08, P.85〜110。"Starting Up IPv6(4), DNS(BIND 9) の運用"。
> IIJ から BIND 9.1.2 を入手してみる。IPv6 での BIND 9 の設定。
「Software Design」`22/09, P.172〜177, "OpenBSD の操縦席, DHCP サ−バ設定[後編]と
> DNS サ−バ設定"。BIND 4 での設定。/24, /26 サブネットの場合。