13.ドメインとDNSの詳細 13-1. ドメインとDNSの基本 (1) ドメインと DNS 動作の仕組み '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 ファイルを設定することで ホスト名の名前解決ができるようになる。Windows や Macintoshにはこのファイルはない。 /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 (2) 2次ネ−ムサ−バの基本 '96 * 基本 ドメインのホスト名を管理するのに、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.jj とする。 ドメイン a( nix.co.jj ) * 種類 named.boot --------------------------------------------------- 自ドメインの正引き情報 |primary nix.co.jj named.hosts の大元を管理してます。 named.boot --------------------------------------------------- 他のドメインのコピ−を |secondary nix.co.jj 192.9.200.1 named.hosts.sec 持ってます。 named.boot --------------------------------------------------- 自ドメインと他のドメイ |primary nix.co.jj named.hosts ンの情報を持ってます。 |secondary nix.co.jj 192.9.200.1 named.hosts.sec named.boot --------------------------------------------------- 自ドメインの逆引き情報 |primary 200.9.192.in-addr.arpa named.rev を持つ場合。 * インタ−ネットでの設定 インタ−ネットに接続した場合、どのようにネ−ムサ−バが記述されるのか示した。2次 ネ−ムサ−バは、接続プロバイダになってもらうことにし、henomohe.or.jj とする。 イ ンタ−ネットから nix.co.jj ドメインのホストへアクセスするには、先ず hostZ の DNS を見てIPアドレスを検索する。 もしこの DNS が落ちていたりしたら hostY の DNS を 見ることになる。 hostY の DNS には named.hosts と named.rev のコピ−を持ってもら う。かつての DNS の仕様では named.rev は無くても構わなかった。しかし最近では外部 のホストにアクセスする際、 認証のため相手が named.rev を見ることが多くなっている。 直ぐに電話を受けるのでなく、掛け直して本当に相手かどうかチェックするのである。 * root | ------------------------------------ | ------- | |hostX| << JPNIC のネ−ムサ−バに nix.co.jj を登録してもらう。 | ------- 逆引きの 128.241.202.in-addr.arpaも登録してもらう。 | | ------------------------------------ jj | | | ------- | ------- | |hostY| DNS2次 | |hostZ| DNS1次 | ------- | ------- | | | | .1 ---------------- --------------- 202.241.128.0 henomohe.or.jj nix.co.jj 自サイトのドメイン [ hostX での DNS の記述 ] JPNIC のネ−ムサ−バ /etc/named.hosts ------------------------------------------- |@ IN SOA .... | | |nix.co.jj. IN NS hostZ.nix.co.jj. << 1次ネ−ムサ−バの記述。 | IN NS hostY.henomohe.or.jj. << 2次ネ−ムサ−バの記述。 |hostZ.nix.co.jj. IN A 202.241.128.1 記述の順番は関係ない。 /etc/named.rev ------------------------------------------- |@ IN SOA .... | | |128.241.202.in-addr.arpa. IN NS hostZ.nix.co.jj. << 逆引き情報の記述。 [ hostY での DNS の記述 ] /etc/named.boot ------------------------------------------- | | ここは henomohe.or.jj 自体 別にどんなファイル名でもいい。 | | の named.boot の設定を記述 ディレクトリ指定を入れてもいい。 | ↓ |secondary nix.co.jj 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.jj /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.jj ドメインのホスト名の情報と、202.241.128.0 ネットワ−クのIPアドレ スの情報をこの DNS は管理している。上位のドメイン、つまり co.jj ドメインから 管理の権限を委譲されているという。nix.co.jj ドメイン、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のネ−ム サ−バに限らず、我々が管理する末端のネ−ムサ−バでも同じ事がいえる。インタ−ネッ トの危険性から身を守るには必要最低限の情報しか外に出さないようするのが無難である。 * 注意 2次ネ−ムサ−バの named.boot にファイル名が、雑誌や本の解説で書いてない場合がま ま見受けられた。もし書いてないと以下の例では、192.9.200.1 のアドレスから1次ネ− ムサ−バの named.hosts を見にいってしまう。このため、もし1次側の named も稼働し てないと、ホストを調べられなくなる。ファイル名の指定のない2次ネ−ムサ−バは、1 次ネ−ムサ−バのバックアップとしては何の意味もない。 named.boot 書いてない場合 ↓ --------------------------------------------------- |secondary nix.co.jp 192.9.200.1 ここが空 named.boot 書いてある場合 ↓ --------------------------------------------------- |secondary nix.co.jp 192.9.200.1 named.hosts.sec * 2つのDNSサ−バの装置で動作を確認してみた `2h/09/e << NetAttest D3 の設定 >> URL名 NetAttest Qube3 server1 [ドメインネ−ムサ−ビス]->[ゾ−ン] 画面にて。 DNS□ DNS□ □ 1次|.7 2次|.8 |.9 DNS - ゾ−ン ------------------------- ----------------------------------------------------- 192.168.1.0 | | ゾ−ン名 | ゾ−ンタイプ | オプション | |----|-------------|--------------|-----------------| | □ | nix.co.jj | master | 許可設定 DNSSEC | DNSサ−バに server1と |----|-------------|--------------|-----------------| いうURL名を問い合わせ | □ | nix.con | master | 許可設定 DNSSEC | て答えることができる設定。 |----|-------------|--------------|-----------------| | □ | server1 | master | 許可設定 DNSSEC | << これだけ "許可設定"を |----|-------------|--------------|-----------------| クリックした。 | □ | server2 | master | 許可設定 DNSSEC | |---------------------------------------------------| DNS - ゾ−ン - 許可設定 --------------------------------------------------------------- |アップデ−トを許可するネットワ−ク/アドレス [ ] | |ゾ−ン転送を許可するネットワ−ク/アドレス [192.168.1.8 ] | |問い合わせを許可するワ−ク/アドレス [ ] | | | | [ OK ][キャンセル] | --------------------------------------------------------------- << Cobalt Qube3 の設定 >> [ネットワ−クサ−ビス]->[DNS]->{サ−バの管理} 画面の(セカンダリサ−ビスを設定)で [セカンダリサ−ビスを追加 ▼] プルダウンして "ドメイン" を選択し以下のようにした。 最初の画面で "DNSサ−ビスを有効にする" に〆をいれ (保存)。これで named が動く。 ----------------------------------------------------- |セカンダリサ−ビスのリスト | Qube3 の namedが起動した |---------------------------------------------------| 時に、DNS1次サ−バでサ− | 1 エントリ| ビスしているゾ−ン情報の |---------------------------------------------------| 中で、server1 というのだ | セカンダリサ−ビス | プライマリDNSサ−バ | 詳細 | け持って来る。server1 は |---------------------|----------------------|------| nix.co.jj と同じくドメイ | server1 | 192.168.1.7 | %# | ン名であることに注意せよ。 ----------------------------------------------------- Qube3 の DNS設定の機能はおかしくなってしまっている。 (プライマリサ−ビスを設定) "レコ−ドを追加" しても表示されてこないのだ。 しかしこの named.conf をみると何や ら追加されている。named.conf ファイル、/etc/named/ 内ファイルを消しても、 どこか に設定を覚えていて、そのファイルが壊れしまったのだと思う。しかし有難いことに、今 回のテストには十分役立った。 /etc/named.conf ----------------------------------------------------- |// BIND8 configuration file |// automatically generated Fri Sep 22 14:26:15 2017 |options { | directory "/etc/named"; | // no forwarders defined | // no zone transfer access defined |}; |zone "server1 " { | type slave; | file "db.server1 "; | masters { 192.168.1.7; }; |}; /etc/named/db.server1 ゾ−ン転送されてちゃんとファイルになっていた。 ----------------------------------------------------------------------------------- |; BIND version named 8.2.2-P5 Wed Jun 14 17:32:48 PDT 2000 |; BIND version root@zerg.cobalt.com:/home/redhat/BUILD/bind-8.2.2_P5/src/bin/named |; zone 'server1' first transfer |; from 192.168.1.7:53 (local 192.168.1.8) using AXFR at Fri Sep 22 14:26:13 2017 |$ORIGIN . |server1 0 IN SOA server1. ikken.nix.co.jj. ( | 2 300 50 2592000 10 ) | 0 IN NS server1. | 0 IN A 192.168.1.9 /etc/named/named_dump.db DNSサ−バのキャッシュ情報をダンプしてみた。 ------------------------------------------------------------------------ |; Dumped at Fri Sep 22 14:26:31 2017 |;; ++zone table++ |; . (type 6, class 0, source Nil) |; time=0, lastupdate=0, serial=0, |; refresh=0, retry=0, expire=0, minimum=0 | | |; server1 (type 2, class 1, source db.server1) |; time=1506057997, lastupdate=1506057973, serial=2, |; refresh=300, retry=50, expire=2592000, minimum=10 |; ftime=1506057973, xaddrcnt=1, state=18041, pid=0 |; z_addr[1]: [192.168.1.7] | | |;; --zone table-- |; Note: Cr=(auth,answer,addtnl,cache) tag only shown for non-auth RR's |; Note: NT=milliseconds for any A RR which we've used as a nameserver |; --- Cache & Data --- |$ORIGIN . |server1 0 IN A 192.168.1.9 ;Cl=1 | 0 IN NS server1. Cl=1 | 10 IN SOA server1. ikken.nix.co.jj. ( | 2 300 50 2592000 10 ) ;Cl=1 (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 * ホスト名検索の例 DNS named.hosts ----- ---------- | | |y.a NS α y.a ドメインの1次ネ−ムサ−バ ----- | NS α' y.a ドメインの2次ネ−ムサ−バ | --------------------------------------------------- a | | | | | 止まっている | | ----- ----- | ----- | ----- ホストAからB | |α'| DNS | B| | | α| DNS | | A| にアクセスする。 | ----- ----- | ----- | ----- | | | | | | | ------------ z.a ---------------- y.a ------------- x.a * サブドメインと主ドメインの関係 ホスト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 管理ゾ−ンの範囲 * 単一ドメインでゾ−ンの管理を委譲しない場合の基本 1つの DNS が管理するゾ−ンは、ネットワ−クのセグメントが違ってもいい。 何となく セグメントが違えば管理は別なような気がするが。下の例では hostA の named デ−モン が hostA,B,C,D ホストのIPアドレスを管理している。 hostA hostB named ■ □ |.1 |.2 ------------------------- 192.9.200.0 nix.co.jj | hostC hostD □ □ □ | |3. |.4 ------------------------- 192.9.201.0 nix.co.jj /etc/named.boot ------------------------------------------------------ |cache . /etc/named.ca |primary nix.co.jj /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.jj. katou.hostA.nix.co.jj. ( | 1 3600 300 3600000 360000 ) | IN NS hostA.nix.co.jj. |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.jj. | IN NS hostA.nix.co.jj. |1 IN PTR hostA.nix.co.jj. |3 IN PTR hostC.nix.co.jj. |2 IN PTR hostB.nix.co.jj. |4 IN PTR hostD.nix.co.jj. /etc/named.local ------------------------------------- |@ のところ上に同じ | IN NS hostA.nix.co.jj. |$ORIGIN 127.in-addr.arpa. |1.0.0 IN PTR localhost.nix.co.jj. /etc/named.ca ロ−カルのネットワ−ク内でのみ使えるル−トのドメイン情報 -------------------------------------------------- |. 9999999 IN NS hostA.nix.co.jj. ドメインのル−トが nix.co.jj |hostA.nix.co.jj. 9999999 IN A 192.9.200.1 ということである。 [ インタ−ネットと接続する場合の上位ドメインでの登録 ] /etc/named.hosts /etc/named.ca はインタ−ネット用の ----------------------------------------- ル−トキャッシュ・ファイルを使う。 |nix.co.jj. IN NS hostA.nix.co.jj. |hostA.nix.co.jj. IN A 192.9.200.1 /etc/named.rev ------------------------------------------------ |200.9.192.in-addr.arpa IN NS hostA.nix.co.jj. |201.9.192.in-addr.arpa IN NS hostA.nix.co.jj. * サブドメインでゾ−ンの管理を委譲しない場合 A ■ B □ |.1 |.2 ------------------------- 192.9.200.0 nix.co.jj | □ C □ D □ | |3. |.4 ------------------------- 192.9.201.0 aaa.nix.co.jj /etc/named.boot ------------------------------------------------------ |cache . /etc/named.ca |primary nix.co.jj /etc/named.hosts |primary 200.9.192.in-addr.arp /etc/named.rev /etc/named.hosts -------------------------------------------------------------- |@ IN SOA hostA.nix.co.jj. katou.hostA.nix.co.jj. ( .. | IN NS hostA.nix.co.jj. |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.jj. |1 IN PTR hostA.nix.co.jj. |2 IN PTR hostB.nix.co.jj. | |$ORIGIN 201.9.192.in-addr.arpa. << こういう記述の仕方もできる。しか |3 IN PTR hostC.aaa.nix.co.jj. し管理するゾ−ンの範囲が分かりに |4 IN PTR hostD.aaa.nix.co.jj. くくなる。あまりよろしくない。 * サブドメインでゾ−ンの管理を委譲する場合 A ■ B □ |.1 |.2 ------------------------- 192.9.200.0 nix.co.jj | □ C ■ D □ | |.3 |.4 ------------------------- 192.9.201.0 bbb.nix.co.jj hostA /etc/named.boot ------------------------------------------------------ |cache . /etc/named.ca |primary nix.co.jj /etc/named.hosts |primary 200.9.192.in-addr.arp /etc/named.rev hostA /etc/named.hosts ----------------------------------------------------------------- |@ IN SOA hostA.nix.co.jj. katou.hostA.nix.co.jj. ( .. |nix.co.jj. IN NS hostA.nix.co.jj. |hostA.nix.co.jj. IN A 192.9.200.1 |hostB.nix.co.jj. IN A 192.9.200.2 | |bbb.nix.co.jj. IN NS hostC.bbb.nix.co.jj. |hostC.bbb.nix.co.jj. IN A 192.9.201.3 hostA /etc/named.rev ------------------------------------- |@ のところ上に同じ | IN NS hostA.nix.co.jj. |1 IN PTR hostA.nix.co.jj. |2 IN PTR hostB.nix.co.jj. hostB /etc/named.boot ------------------------------------------------------ |cache . /etc/named.ca |primary bbb.nix.co.jj /etc/named.hosts |primary 201.9.192.in-addr.arp /etc/named.rev hostB /etc/named.hosts ------------------------------------------------------------------------- |@ IN SOA hostC.bbb.nix.co.jj. katou.hostC.bbb.nix.co.jj. ( .. |bbb.nix.co.jj. IN NS hostC.bbb.nix.co.jj. |hostC.bbb.nix.co.jj. IN A 192.9.201.3 |hostD.bbb.nix.co.jj. IN A 192.9.201.4 hostB /etc/named.rev ----------------------------------------- |@ のところ上に同じ | IN NS hostC.bbb.nix.co.jj. |3 IN PTR hostC.bbb.nix.co.jj. |4 IN PTR hostD.bbb.nix.co.jj. [ インタ−ネットと接続する場合の上位ドメインでの登録 ] /etc/named.hosts ----------------------------------------- |nix.co.jj. IN NS hostA.nix.co.jj. << bbb.nix.co.jj のゾ−ン情報はここ |hostA.nix.co.jj. IN A 192.9.200.1 を辿って検索されることになる。 /etc/named.rev --------------------------------------------------- |200.9.192.in-addr.arpa IN NS hostA.nix.co.jj. |201.9.192.in-addr.arpa IN NS hostC.bbb.nix.co.jj. (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 9.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アドレスをキャッシュする。`27/12追記、djbdns はその後、広まったか。どうもそんな感じではない、IIJ もずっと BIND のままだし。 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設定のチェックサイトというのがある。きちんと named.conf やゾ−ンファイルが 書かれているか調べてくるのだ。「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/ の「DNSの基礎知 識」も参照されたい。正しいDNSの制御ファイルを記述しないと、その内にインタ−ネ ットが機能しなくなってしまうかも知れない。その可能性はだいぶあるような気がしない でもない。DNSの設定をする業者はあまたあるが、結構やっつけ仕事のようである。 * 正しい制御ファイルの書き方 [その1] 正引きファイル ---------------------------------- |@ IN NS ns1.nix.co.jj. << | IN NS ns2.nix.co.jj. << このように書くと CNAME 以外のレコ−ドは無 | IN CNAME hostA.nix.co.jj. 視される。記述した NSレコ−ドの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 MX 10 mail.nix.co.jj. |mail IN CNAME hostA << 間違いではないが、 相手は検索するのに二度 |hostA IN A 192.168.1.1 手間になる。止めた方がいい。NS レコ−ドで も同様なことである。NS と MX レコ−ドでは ↓ こうすること CNAME を使わずに A レコ−ドで直ちにIPア ドレスに対応させること。 ---------------------------------- |@ IN MX 10 mail.nix.co.jj. |mail 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 の例 ----------------------------------- 86400秒:24時間。21600秒:6時間。1200秒:20分。 |$ORIGIN example.jp. |$TTL 86400 << アクセスしに来たネ−ムサ−バには1日キャッシュされる。 |@ IN SOA ns1.example.jp. hostmaster.example.jp. ( | 2002121901 ; Serial � \ | 86400 ; Refresh |これらはスレ−ブからマスタ−への | 21600 ; Retry |ゾ−ン転送の要求に関わる変数の値。 | 2419200 ; Expire /� | 1200 ; SOA TTL ( Negative Cache )、BIND 4.x ではここが Minimum TTL。 | ) Serial --- BIND では YYYYMMDDnn が推奨されている(RFC1912)。 Refresh -- BIND 8 以降には Notify 機構があるので、あまり気にしなくてもいいらしい。 基本的には1次ネ−ムサ−バにアクセスして、 シリアル番号が増加していれ ば、2次ネ−ムサ−バ側にコピ−してくる時間間隔。以前、BIND 8 系列での ことで1時間とか数時間程度が望ましいらしいと調べて書いたことがある。 Retry ---- Refresh 時間でゾ−ン転送できなかった場合、 成功するまで繰り返す時間間 隔。限度は Expire の時間になる。Refresh 時間の数分の1の値にする。 Expire --- Refresh の時間より大きくすること。RFC1912 によれば通常は2〜4週間。 SOA TTL -- 数10分程度、RFC2308 のサンプルは20分(1200)。 存在しないホスト名を アクセスした場合、それを記憶しておく時間。 $TTL ----- キャッシュ時間。1日から3日、RFC2308 のサンプルは1日(86400)になって いた。BIND 4.x 代での Minimum TTL( SOA TTL ) がこの値である。 かつて SOA TTL の値は1〜5日が適切とされてきた(RFC1912)。BIND 8.2 以降、 TTL の 意味が変わり $TTL が新設された。BIND 8.x では $TTL の記述がないと SOA TTL の値が $TTL として取られる。BIND 9 では $TTL を記述してないと named起動時にエラ−となる。 ・Refresh 値を長い時間に設定してしまった場合、その間にDNSのレコ−ド情報を変更 しても、2次ネ−ムサ−バに反映されるのは Refresh 時間後になる。 ・因み djbdns では Serial 値は、ファイルのタイムスタンプから自動生成されるように なっている。それに djbdns はゾ−ン転送機構は使わないので Refresh 値は関係ない。 ・BIND 8 からできた Notify 機構がデフォルトで働くようになっている。 Refresh 時間 を待たずにゾ−ン転送が行われる。ただし Serial 値はこの場合でも関係する。 ・秒数と時間:3600 1時間、300 5分、3600000 約6週間、360000 100時間、約4日。 * Lame Delegation について `28/08 DNSの管理で不十分な委譲をしてないかという話。だいぶの間、何のことかよく分から なかった。JPNIC から2008年5月22日にきたメ−ル、件名 lame-notify@nic.ad.jp の"逆引きネ−ムサ−バの適切な設定についてのお願い"。インタ−ネットの安定した運用 のため、2008年7月1日から lame delegation の状態にある逆引きネ−ムサ−バの 通知と委任停止を実施する。毎日チェックして15日間おかしい状態のままであればメ− ルで通知し、45日間ずっとおかしいことが確認できたら委任停止する。特に通知メ−ル も来ることはなく過ぎて行ったのだが、2008年8月13日にまた JPNICからメ−ルが きた。運用に問題が見つかったのでしばらく対策を止めるとのこと。自社のDNSの設定 がおかしくて通告がきたのかと思ったが、JPNIC 自体の問題で委任停止の実施を中止する ということだった。しかし慌てた。相手が逆引きチェックしていたら、当社のホ−ムペ− ジにアクセスできなくなったり、メ−ルが送れなくなったりするかもとびっくりしたぞ。 それで雑誌なんかの Lame Delegation の記事を、よく読んでみた。 信用のおけるプロバ イダからパブリックIPアドレスを振ってもらっていて、DNSの2次ネ−ムサ−バにも なってもらっていれば、問題は起きようがない。インタ−ネットではDNSサ−バは幾つ か設けることになっている。nix.co.jp のDNSサ−バは、.jp ドメインに登録してもら う。1つは自社で運用するDNSサ−バであり、これが1次ネ−ムサ−バである。もう1 つは接続プロバイダのDNSサ−バを登録する。一応接続プロバイダにお願いして、プロ バイダのDNSサ−バ内で2次ネ−ムサ−バになってもらう。これが当初のDNSサ−バ 管理の在り方である。接続プロバイダが倒産すれば、インタ−ネットにそもそもつなぐこ とが出来なくなる訳でDNSもへちまもない。だから、こうした素直なインタ−ネット接 続しているところは Lame Delegation のような問題は起きることはないのである。 接続プロバイダ以外でドメイン名を取っている場合は、問題が起きる可能性はある。つま り別な業者にDNSの2次ネ−ムサ−バになってもらっている場合である。その業者が夜 逃げしてしまい、悪意のある第三者が2次ネ−ムサ−バの内容を変えてしまったら。2次 ネ−ムサ−バは本来は1次ネ−ムサ−バからデ−タを引っぱってくるのだが、別に直接記 述することだってできてしまう。そうなったらもうやりたい放題になる。.jp ドメインか らは1次も2次ネ−ムサ−バも一緒な訳で等しく利用される。2次ネ−ムサ−バの方を見 たユ−ザは、第三者が用意した偽のホ−ムペ−ジに誘導されるし、メ−ルも偽のMXレコ −ドに飛ばされることだって有り得る。ともかく一杯ドメイン名を取っていると知らずに 起こる可能性が増える。ちゃんとドメイン名は管理しておかないと危ない。用もないのに ドメイン名を取るのは止めた方がいいということである。 * 参考文献など `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 で BIND-8.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 サブネットの場合。