さて， ドメイン・ネーム・システムの仕掛けを一通り紹介しましたが， ネーム・サーバーには2つのタイプがあることに気付かれましたか。
1 つは /etc/resolv.conf に登録できるネーム・サーバーで， nslookup 等のクライアントから問い合わせがあると， 他のネーム・サーバーに問い合わせて結果をクライアントへ返してくれるタイプです。
もう1つは， 答えを知っている問い合わせに対しては答えてくれるけれど， 知らない場合は， どこどこへ聞けと冷たく言い放つタイプです。 このタイプは自分から他のネーム・サーバーへ問い合わせようとはしません。 問い合わせませんから結果を覚えておくためのキャッシュも必要ありません。 前述した例で言えば， ルート・サーバーがこのタイプに当たります。
ここでは便宜上， 前者のタイプをクライアント型ネーム・サーバー， 後者をサーバー専業型ネーム・サーバーと呼ぶことにします。
常時接続環境で独自のドメインを持とうとするとき， どちらのタイプのネーム・サーバーを立ち上げるべきでしょうか。 クライアント型ネーム・サーバーもネーム・サーバーですから， 答えを知っている問い合わせに対しては答えてくれます。 つまりサーバー専業型ネーム・サーバーの動作を完全に含んでいます。 したがってクライアント型ネーム・サーバーを立ち上げておけば 間違い無いように思われます。 実際， ネーム・サーバーに関する記事等では， クライアント型ネーム・サーバーの立ち上げ方法しか 解説していないものがほとんどです。
ところが， セキュリティの観点から言うと， クライアント型ネーム・サーバーはあまり好ましいものではありません。 クライアント型ネーム・サーバーは， 他のネーム・サーバーに問い合わせた時に得られた結果をキャッシュに記憶しますが， 問い合わせ先のネーム・サーバーが間違った結果を返したらどうなるでしょうか。
そうなると間違ったデータをキャッシュに記憶してしまい， 同様の問い合わせがあると， その間違ったデータを返してしまうようになります。 実際， 故意に間違ったデータを送りつけておいて， ホスト名を詐称する攻撃方法が知られています。
また， クライアント型ネーム・サーバーは， ドメインに関する問い合わせを受け取ると， そのドメインのネーム・サーバーに対して問い合わせることになり， いわば外部からの要求の「言いなり」になっています。 攻撃者側から見ると攻撃のための便利な道具と言えます。
いずれにせよ， クライアント型ネーム・サーバーは， サーバー専業型ネーム・サーバーに比べると， 問い合わせを行う分動作が複雑ですから， セキュリティ・ホールが入り込む余地が多いわけです。 サーバー専業型ネーム・サーバーで十分であれば クライアント型ネーム・サーバーを立ち上げるべきではありません。
では， クライアント型ネーム・サーバーが必要となるのはどんな場合でしょうか。 それは nslookup をはじめとするクライアントが 直接問い合わせる可能性があるネーム・サーバーということになります。 つまり /etc/resolv.conf や Windows98 等の「DNS設定」に登録する ネーム・サーバーは， クライアント型ネーム・サーバーでなければなりません。 つまり組織内部で使うネーム・サーバーです。 プロバイダがユーザーに対して提供するネーム・サーバーも， クライアント型ネーム・サーバーです。 クライアント型ネーム・サーバーは， 先ほど紹介したような攻撃から守るために， 組織外部から勝手にアクセスされないよう， ファイアウオール等で守っておく必要があります。
一方， 組織外部からの問い合わせに対しては， 自組織に関する問い合わせに対してだけ答えれば十分ですから， サーバー専業型ネーム・サーバーで構わないことになります。 第三者のドメインに関する問い合わせに対しては 「知らない」と突っぱねればいいのです。 余計なサービスをしてセキュリティを犠牲にすべきではありません。
まとめると， 組織内部で使うためにクライアント型ネーム・サーバーを立ち上げ， 組織外部に対しては， サーバー専業型ネーム・サーバーを立ち上げるようにすれば良いことになります。
このように， 内部と外部， それぞれに対してネーム・サーバーを立ち上げると， 組織外部に公開したくないホスト名をいんぺい（隠蔽）できる， というメリットもあります。
例えば GCD 内部では，mucho.gcd.org というホスト名を引くことができますし， 逆に IP アドレス 210.145.125.161 から mucho.gcd.org を得ることもできます（図11（a））。
しかし， mucho.gcd.org は外部からアクセスする必要が全く無いマシンです＊16。 したがって外部向けのネーム・サーバーには登録してありません。 このため， GCDの外部（以下の例では cybird.co.jp ）では， mucho.gcd.org を引くことはできませんし， 逆に IP アドレスから引くこともできません。 もちろん外部に公開している www.gcd.org ならば検索できます（図11（b））。
図11 内部からのみDNS情報を得られる GCD内部では，mucho.gcd.orgというホスト名を引くことができる（a）。 しかし外部からは， mucho.gcd.org に関する情報は得られないようになっています（b）。 |
|
組織外部向けと内部向けの2つのIPアドレスを持っているマシンの場合， 外部向けネーム・サーバーと内部向けのネーム・サーバーに 異なるIPアドレスを付けることもできます。 例えば， asao.gcd.org は GCD 内部と外部では IP アドレスが異なります。 内部ではプライベート・アドレス 192.168.1.1（図12（a））ですが， 外部から見ると， グローバル・アドレス 210.145.125.162（図12（b））です。
図12 内部と外部とでIPアドレスが違うホストも設定可能 内部ではプライベート・アドレス(a)， 外部ではグローバル・アドレス(b)を持つホストの例です。 |
|
次回は， 今回の内容を踏まえて， ネーム・サーバーの実際の構築法を紹介します。 連載第 1 回で紹介したように， GCD のゲートウエイはマシン 1 台だけで， しかも NIC は 1 枚しかありません。 このゲートウエイで GCD の内部向けと外部向けのネーム・サーバーを立ち上げ， しかもセキュリティに配慮した構築法を解説します。
(ライターから)
本稿は日経Linux 2000 年 5 月号に掲載された、 実践で学ぶ、一歩進んだサーバ構築・運用術, 第 2 回「ネームサーバ (前編)」を日経BP 社の許可を得て転載したものです。
Copyright(C)2000 by 仙石浩明 <sengoku@gcd.org>
無断転載を禁じます