ルートサーバー - みる会図書館


検索対象: UNIX MAGAZINE 1997年7月号
107件見つかりました。

1. UNIX MAGAZINE 1997年7月号

ているのであれば、 DNS に関してはインターネットと直 孑妾続しているとみなすことができます。この場合の設定 は前回までと同しですから、説明は省略します。今回は、 DNS バケットがファイアウォールで遮断されていても、 内部ネットワークで DNS が利用できる方法を解説しま す。 ファイアウォールとして UNIX ワークステーションを 使っているのであれは、内部から外部への DNS は引ける が、外部から内部への DNS は引けないようにするという 設定も可能です。 前回の設定の場合、インターネットと接続されていなけ れ tiDNS サービスカリ用できないのは、インターネット 上にあるルートサーバーへのアクセスが必要だからです。 ファイアウォールで防御されたネットワーク内で DNS を使う場合、内部ネットワーク専用のルートサーバーを用 意します。以後このルートサーバーを、、内部ルートサー " と呼ぶことにします。内部ネットワークの各 DNS サーバーは、ルートサーバーへのアクセスが必要になると 内部ルートサーバーヘアクセスします。もし、内部ルート サーバーがインターネットのルートサー ーと同じ挙動を 示せば、内部ネットワークの DNS サーバーはなんら地 なく衄乍します。 基本的に、必要な竹喋は次の 2 つです。 1. 内部ルートサーバーを準備する。 2. 各 DNS サーバーカ吶部ルートサーバーを参照するよう 連載 / IJN Ⅸ知恵袋ーの 言殳定の要点 ましよう。 それでは、 に定する。 これらの設定について具イ勺に説明していき UNIX MAGAZINE 1997.7 イルを用意します。つまり、ネームサーバーの言ファイ 具イ勺な設定としては、ルートドメイン (. ) のゾーンファ は、ルートドメインを管理するサーバーであることです。 とにちがいはありません。通常のネームサーバーとの相違 ルートサーバーといえども、ネームサーバーであるこ 内部ルートサーバーの設定 図 1 ルートサーパーの named. boot directory pr lmary /var /name d root .20 Ⅱ e ノレ named. boot とゾーンの疋ファイノレ *. zone を、ノレー トサーバー用に新たに作ることになります。 以後、 f00. co. jp のファイアウォールが DNS をい っさい通さない、もしくはインターネットに接続されて いないとして、 foo. co. jp 内にルートサーバーを立ち上 げる方法を考えます。 foo. co. jp のルートサーバー名を rootns. f00. co. jp とします。 図 1 と図 2 に例を示します。適宜、例と見くらべながら 読み進めてください。 通常のネームサーバーの設定ファイルについての理解が あれは、ルートサーバーの設疋ファイルも難しくはありま せん。まず、ネームサーバー自体の設定ファイルである named. boot ( 図 1 ) を見ていきましよう。 directory 行で は、ネームサーバーのゾーンファイルを置くディレクトリ を指定します。 directory /var/named この例では、 /var/named 以下にゾーンファイルを置 くように指定しています。 次の primary 行では、このネームサーバーか管理する ドメインと、そのドメインの情報を言己したファイルを指 定します。 prxmary root . zone ルート・ネームサーバーですから、管理するドメイ ンはルート (. ) になります。ルートドメインの情報は、 root. zone ファイルに言当されており、 directory 行でオ旨 定した /var/named の下に置かれます。 root ・ zone にはルートドメインの設定か書かれます。通 常、ルートドメインに言 t 算機を置くことはないので、設 定内容は下位ドメインの権威づけだけになります。ます、 SOA レコードで設定ファイルがルートドメインの内容で あることを指定します。次に、ルートドメインを管理する 63 NS rootns . f00 . co ・」 p ・ ーは rootns. f00. co. jp ですから、 ネームサーバーを NS レコード定します。ルートサー IN

2. UNIX MAGAZINE 1997年7月号

連載 / UN Ⅸ知恵袋ーの 図 4 内部ネットワークの各ネームサーバーのファイル /var/named f00 ・ co ・ JP 159. 133. in—addr . 図 5 内部ネットワークのネームサー 99999999 ・ co ・ jp. 99999999 directory cache pr prmary pr lmary rootns . f00 root . cache f00 . zone f00 . rev 0.0.127. in—addr. arpa localhost . rev ′く一の root. IN NS rootns . f00. co ・」 p ・ IN A 133. 159.48.1 最後に逆引きの委譲です。 foo. co. jp が 133.159 / 16 の ネットワーク・アドレスをもっていて、 ns. foo. co. jp と ns2. f00. co. jp がネームサーバーであるとすると、 159.133.1 Ⅱー addr. arpa. IN NS Ⅱ s . f00 . co ・ jp ・ IN NS Ⅱ s2. f00. co ・ JP ・ のように孑定することになります。 foo ・ co. jp 以外に管理するドメインが必要ならば、権 限の委譲の項目を必要なドメインの数だけ追加しておき ます。 以 . E の設定で、 rootns. foo. co. jp カ吶部ルートサー として動作する準備ができました。 named を起動して、 nslookup コマンドて市薩忍してみましよう。図 3 を見てく set type=ns" でネームサーバーの情報を指定 ださい。 し、 foo. co. jp のネームサーバーを問い合わせます。正し い出力カ碍られたら、内部ルートサーバーは正しく衄乍し ています。 図 3 では、 nslookup 起動直後のデフォルト・ネー ムサー / ヾーが ns. f00. co. jp になっています。 nslookup 起重加のネームサーバーは、 /etc/resolv. conf の成疋に よって決定されます。この例では、 /etc/resolv. conf で ns. foo. co. jp がネームサーバーとして設定されています。 ネームサーノヾーの IP アドレスを localhost に設定して おくことで、 nslookup 起重加のデフォルト・ネームサ ーバーを localhost 、すなわち内部ルートサーバーにす ることもできます。しかし、 rootns ・ foo ・ co. jp の運用を 考えると、Ⅱ s. f00 ・ co ・ jp にしておいたほうがよいでしよ う。なぜなら、名前を解決するとき、 /etc/resolv. conf に 指定されているネームサーバーに最初に問い合わせるか らです。 foo. co. jp の計算機の名前を問い合わせるとき、 rootns. foo ・ co ・ jp に向かおうとしても、けっきよくは内部 ルートサーバーから ns. foo. co ・ jp に向かうように指小さ UNIX MAGAZINE 1997.7 れるだけです。最初から ns. foo. co. jp に問い合わせるよ うに設定しておけば、無用なトラフィックを減らせます。 各ネームサーバーの設定 内部ネットワークの各ネームサーバーは、ほとんど変 更する必要がありません。なぜなら、内部ルートサー を本当のルートサーバーと思って衄乍するからです。設定 は、内部ルートサ→ヾーをルートサーバーとして認識する ように変更するだけです。 設定ファイルの例を図 4 ~ 5 に示します。 図 4 が内部ネームサーバーの成疋ファイルです。特別 な設定は何もしていないことが分かります。変更が必要な のは、図 5 に示したルートサーバーを記述したファイル root. cache です。これまでの成疋では、 root. cache にイ ンターネット上のルートサーバーを書いていました。今回 は、内部ルートサーバーを書きます。 設定か完了したら、ネームサーバーを起動して重川乍を確 認してください。 nslookup コマンドで名前を間い合わせ てみます。 foo. co. jp ドメインに関しては、通常どおり名 前を引くことができます。 foo. co. jp ドメイン以外のドメ インに対する問・をには、すべて該当する名前は存在しな いというメッセージが出ます。たとえば、 www.ibm.com を問い合わせると以下のようになるはすです。 * * * f00. CO. 」 p find VVV. ibm. com. : Non—eXIS tent host/domain サブドメインを作る 内部ルートサーバーを利用している状況で、 foo. co. jp の下にサブドメインを作りたくなったとしましよう。こ の場合、正引きの設定はインターネットに接続されている 65

3. UNIX MAGAZINE 1997年7月号

連載 / IJN Ⅸ知恵袋ーの 図 2 ルートドメインのゾーンファイル ・ co ・コ P ・ IN A IN NS IN A IN A IN NS となります。もっとも、ルートドメイン以下のすべてを管 理できるわけですから、ルートサーバーの名前としてわざ IN SOA rootns . f00 1 86400 3600 604800 86400 ) IN NS て 00t Ⅱ s . f00 て 00t 取 s . f00. CO ・」 p ・ f00 ・ co ・ JP ・ ns . f 00. co ・」 p ・ Ⅱ s2. f00. co ・ jp ・ 159.133. in—addr. arpa ・ postmaster. f00. CO ・」 p ・ mlnllnum explre retry refresh serial IN IN NS NS 133. 159.48.1 ns. f 00. co ・ j p ・ ns2. f00 . co. 」 p ・ 133. 159.48.10 133. 159.48.11 ns. f 00 ・ co. 」 p ・ ns2. f 00 . co ・」 p ・ わざ foo. co. jp ドメインを選ぶ必畯はありません。しかし、 新たなドメインにしてしまうと、けっきよくはそれも管理 しなければならなくなるので、自分のドメイン名を付ける ほうカ吶単でしよう。 NS レコードを言当したら、忘れすにルートサーバーの A レコードを言己主しておきます。 root Ⅱ s. f00. co ・ jp. 604800 IN A 133.159.48.1 図 2 の例では、 133.159.48.1 に rootns. f00. co. jp とい う名前を付け、ルートサーバーにしています。 ルートサーバー自身の資源レコードの設定か終ったら、 必要なドメインを権威づけします。ここで、糸寸に必要な のが foo. co. jp ドメインです。このドメインを管理するた めに、 ns. f00. co. jp と ns2. f00. co. jp という 2 台の言算 機を用意したとします。それらに、 foo. co. jp を管理する 図 3 内部ルートサーパーの乍確認 rootns. f00. CO. jp# nslookup Defau1t Server: ns . f00 ・ co ・ JP Address: 133. 159.48. 10 > server localhost DefauIt Server: localhost. f00 . co. 」 p Address : 127.0.0. 1 > set type=ns > f00. CO . j p ・ ←ネームサーバーの情報を選択 ← fi 。。 . c 。 . jp の情報を取得 Server: 10ca1host . f00 . co 127.0.0. 1 Address : Non—authoritative answer : f00. co ・」 p nameserver = f00 ・ co ・ JP nameserver Authoritative answers can f00 . co ・」 p nameserver f00 ・ co ・」 p nameserver Ⅱ s. f00 . co. 」 p Ⅱ s2. f00. co. 」 p be found from: Ⅱ s. f00 ・ co ・ JP Ⅱ s2. f00 . co ・ JP ns . f 00. co ・」 p 48 . 10 Ⅱ s2. f00. co . 」 p 48 . 11 internet address = 133. 159. internet address 133. 159. 権限を委譲します。 f00 ・ co ・ jp ・ IN NS ns . f00 ・ co ・」 p ・ IN NS Ⅱ s2. f00. co ・」 p ・ 4 月号で説明した、下位ドメインの管璢在限を下位ドメ インのネームサーバーへ委譲する設定とまったく同じであ ることが分かると思います。つまり、ルートドメインの下 位ドメインである foo. co. jp ドメインを管理する権限を、 ns. f00. co. jp と ns2. f00. co. jp に委言襄するのです。 A レコ 64 ードも同時に設定してください。この例では ns. foo. co ・ jp を 133.159.48.10 、 ns2. f00. co. jp を 133.159.48.11 に しています。 ns . f00. co ・ JP ・ ns2. f00. co. jp ・ IN A IN A 133. 159.48. 10 133. 159.48. 11 UNIX MAGAZINE 1997.7

4. UNIX MAGAZINE 1997年7月号

UN Ⅸ知恵袋 ネームサーバー ( 4 ) インターネットの発展にともない、インターネットを悪 用する人も増えているようです。ネットワークとは人と人 との繋がりだと思います。すなわち、ネットワークと現実 の社会は本質的には同しものといえるでしよう。インター ネットか社会の . 央だとするならば、実社会から犯罪がな くならないように、クラッカーも存在し続けるのかもしれ ません。 インターネットの恩恵を安全に享受するため、多くの組 織ではインターネットとイントラネットとのあいだにファ イアウォール (firewall) と呼はれる頑強な防壁を構築し ています。ファイアウォールによってより安全な通信が 確保できる反面、糸哉内外のユーサーの利便生はどうして もキ生になってしまいます。しかしながら、アタックを受 けたときの被害の大きさを考えれは、致し方のないところ でしよう。 ファイアウォールの基本的な考え方は、自組大」のネッ トワークとインターネットとの通信を遮析することて安全 性を確保するというものです。どうしてもインターネット と通信しなければならないものだけを明示して転送し、必 要最低限の通信をおこなうイ督はみです。 ーロにファイアウォールといっても、ルータを利用し たもの、 UNIX ワークステーション上にソフトウェアを 載せたもの、専用ハードウェアと専用ソフトウェアとを組 み合わせたものなどがあります。それそれ一長一豆があり ますが、ここではルータを使ったファイアウォールを前提 に説明します。 ルータには、その上で何か別のソフトウェアを動かし て特別な処理をさせることができない、という制約があり ます。何カ畤別なことをしたい場合には、ルータの両側に なんらかの装置もしくはソフトウェアを置く必要がありま 62 す。詳しくは、このあとで述べていきます。 今回は、このようなファイアウォールで防御されたネッ トワーク内で DNS を利用する場合の設定を角縊見します。 DNS とファイアウォールの関係 さきほども述べたように、ファイアウォールの基本は通 信の遮析てす。つまり、 DNS に関係する IP バケットを j 面茴させるように明示的に設定しないかぎり、前回の設定 のまま内部ネットワークで DNS を利用することはできま せん。 あるいは、 DNS サーピスを利用する際に、かならすし もインターネットと接続されている必要などないのではな いか、と思われるかもしれません。しかし、前回までの 角得見を思い出してください。ネームサーバーは、自分では 処理しきれない上位アドレスの名前の角夬を要求された場 合、ルートサーバーに問合せにいきます。ルートサーバー は全世界に散らばっていますから、ルートサーバーとの通 信は必然的にインターネットを経由することになります。 ファイアウォールで DNS のバケットを通過させること さえできれは、前回までと同じ設定で DNS カ硬えるよう になります。ファイアウォールを設けているにもかかわら ず、インターネットからその系哉の内部ネットワークの計 算機名を nslookup コマンドなどで見ることかできる場合 は、前述のような設定がなされているはすです。これは、 研究組織や大学などの学彳付機関で多くみられる設定です。 しかし、多くの企業は社内ネットワークに存在する言 1 算 機名が外部に漏れることを嫌います。このため、ファイア ウォールで DNS を遮断してしまうのが一勺です。 ファイアウォールの設定で DNS を通過させるようにし UNIX MAGAZINE 1997.7

5. UNIX MAGAZINE 1997年7月号

Address* : 連載 / UN Ⅸ知恵袋ーの 問合せ先のネームサーバーを server に変更します。 133. 159.48.45 叩。〃には、以下で説明する nslookup の対話モード でのコマンドがそのまま使えます。たとえば、対話モード で、 querytype=A" としたときと同し動作をオプショ ン・スイッチで実現するには、次のように入力します。利 用できるオプション・スイッチについては以降の角見をみ てください。 $ nslookup —querytype=A alpha. f00 ・ co ・ JP Server : rootns. f00. CO ・ JP Address*: 133. 159 .48.1 Name: alpha. f00. co ・」 p Address*: 133. 159.48.45 ん。 s 。れ d で言 t 算機名を指定しなかった場合には、 nslookup コマンドは対話モードになります。対話モード ・ん OSt れ佖 7 れ e では次のコマンドカイ吏えます。 に指定されたネームサーバーに問い合わせます。 ます。 server が省略されたときは、 /etc/resolv. conf ん。 s 。 me で指定した言 t 算機名を serve 日こ間い合わせ ・ lserver server ・ server server に現在成疋されているネームサーノヾーを用い、 lserver server コマンドを使うと、 server 自体の名前の問合迂 コマンドを使うと最初に言殳定されていたネームサーバー ・ root を用います。 UNIX MAGAZINE 1997.7 叩。れには以下のものがあります。 できます。 ダイレクションを使って、ファイルに出力することも 面 m れて指定した名前に関する 1 辭にを表示します。リ ・ ls [ 0 0 司 dom れ [ > > filename] ・ ls [ 02 0 司 dom れ [ > 五 le れ am 司 す。ルートサーバーは ns. internic. net です。 問合せ先のネームサーバーをルートサーバーに変更しま -t 9 社 e 型 t e e 型 t e で資源レコードを指定します。おもな資 せんが、イ更自 : 的に利用できます。 すべての情幸比これは資源レコードではありま ANY 委調辭に SOA (Start Of Authority) 逆引き情報 PTR (PoinTeR) ネームサーバー情報 NS (Name Server) メール転送先↑帯長 MX (MaiI eXchanger) 計算機情報 HINFO (Host INFOrmation 別名レコード CNAME (Canonical NAME) アドレスレコード A (Address) 源レコードには以下のものがあります。 -h -d ・ View 、〃 le れ佖 7 〃 e -t HINFO と同しです。 -t ANY と同しです。 -t CNAME と同しです。 69 インターネットを表します。通常はこの設定し IN とはないでしよう。 る値は次のとおりです。もっとも、 IN 以外を使うこ 問い合わせるクラスを言聢します。拠ん e に指定でき cla.ss==class 現在の設定を表示します ( 図 9 ) 。 囮。は次のとおりです。 ん e リ。に値ん e を設定します。利用できるん e リ - ・ set ん e 0 [ = 0 ん e ls コマンドで出力したファイルを表示します。

6. UNIX MAGAZINE 1997年7月号

連載 / UN Ⅸ知恵袋ーの 図 10 ndc コマンドの書式 ndc 市 7 、 ec 厖 e [. root:=rootserver UNIX MAGAZINE 1997.7 が 0 以外のときは、 /var/tmp/named. run にデバッ ルが 1 つ上がり、 notrace で 1 つ下がります。レベル テンヾッグレベルを成疋します。 trace を指定するとレベ ・ no]trace 統計を /var/tmp/named. stats に出力します。 ・ stats せるために利用します。 ます。ゾーンファイルを更新したときに、更新を央さ ネームサーバーのデータファイルの再言もムみをおこない ・ reload かを調べることができます。 されているか、不正なデータがキャッシュされていない 出力ファイルの内容を見ることで、正しいデータが当求 出力します。出力はゾーンファイルの書式と同しです。 ュしているデータを /var/tmp/named-dump. db に 現在ネームサーバーが一尉寺しているデータと、キャッシ ・ dumpdb す。 現在の状況を表示します。 ps コマンドの表示と同じで ・ status directive に指定できる命令は次のとおりです。 に示します。 スの再第ムみなどができます。 ndc コマンドの書式を図 10 と、ネームサーバー・プロセスの開始や終了、データベー ム ) を制御するためのコマンドです。このコマンドを使う ndc は、ネームサーバー・プロセス (named プログラ ndc コマンド しれません。 が、この連載に出てきた以、タ ) ものを使うことはまれかも nslookup にはたくさんのコマンドが用意されています 時間を指定します。 問・に対する答が返ってくるまでのタイムアウト timeout=time ルートサーバーを rootserver に成疋します。 ク請幸肋ゞ出力されます。 ・ querylog 問合せをログに言求します。トグルスイッチです。ログ は syslog の設疋に従って出力されます。 ネームサーノヾー ・ restart ・ stop ネームサーノヾー ・ start ・プロセスを再起動します。 ネームサーバー・プロセスを停止します。 ・プロセスを起動します。 71 ( しま・けいいちシャーフ ) 分に検討したうえで尺するようにじ掛けましよう。 織の実状に応して必喫とされる機能は変わってきます。十 今回すこしだけ触れたファイアウォールについても、組 けることでしよう。 今後も、インターネット技術のなかで重要な位置を占め続 に認識するような機溝を付加する試みがなされています。 か読けらセキュリティ冫欟冓や、引・算機の移動を自重加勺 DNS は古くから利用されてきた技術です。現在も改良 識は不可欠です。 ばなりません。そのためにも、ネームサーバーに関する知 ないので、必名勺に内部に DNS のイはみを構築しなけれ イベート・ネットワークはインターネットに直孑妾続でき ネットワークを構築する場合も多くなってきました。プラ 描丘は、 IP アドレス窈曷にともない、プライベート・ データベースの更新かできるにこしたことはありません。 新したいものです。わざわさフ。ロバイダに頼ます、手許で 成を変更した場合はただちにネームサーバーのデータも更 れるかもしれません。しかし、現実的に考えると、内音財冓 ネームサーバーの設定は、プロバイダか肩代わりしてく 以 E でネームサーバーの解説を終ります。 ☆ よっ。 イルの更新を反日央させるとき以外はほとんど使わないでし 動作し続けます。 ndc コマンドは、データベース・ファ ファイルから起動さ計算機がシャットダウンするまで 通常、ネームサーバー・プロセスは引・算機の起重加叔こ rc

7. UNIX MAGAZINE 1997年7月号

おうちでらんラン LAN 第 3 回 あつぶる : やらし一 dhcpdb. pool のフィールドに設定される値の型 表 3 dhcpdb. pool で用いられるフィールド ( 一部 ) str s ん 0 あれ 9 iplist 型 定義 文字列。帯未文字 ( コロンなど ) を用いる場合は”て括る 16bit 整数 32bit 整数 単独の IP アドレス 空白で区切られた複数の IP アドレスのリスト IP アドレスの組のリスト。各 IP アドレスは空白て区切ら 2 つ 2 組で扱われる dhcpdb. pool のフィールドー覧 フィールド名型 tblc ipad maxl dfll snmk t mof rout dnsv hstn dnsd brda st rt niSd IIISV ntsv Xdmn dhtl dht2 str あれ 9 あれ 9 Z07 四 ゆ list ゆ s str str 硯 7 、 s s ・ ゆ list iplist s ん 0 s ん 0 機能 別のエントリの参照 クライアントに割り当てる IP アドレス 許容する最長有限 ( 秒 ) クライアントから窈旨定がない場合のデフォルトの有期限 割り当てる IP アドレスのネットマスク グリニッジ標まからの差分秒 クライアントカ材妾続されたネットワークのデフォルトゲートウェイ・アドレス XDM サーバーのリスト NTP サーバーの IP アドレスリスト NIS サーバーの IP アドレスリスト NIS のドメイン名 羸均ルーティングのための宛先とゲートウェイ・アドレスの組のリスト クライアントカ甘妾続されたネットワークのプロードキャスト・アドレス DNS のドメイン名 クライアントのホスト名 DNS サーバーの IP アドレスリスト クライアントカワ・ロードキャストによって有効限延長をおこなう時期の クライアントがユニキャストによって有期限延長をおこなう時期の設定 あつぶる : ところで、 DHCP サーバーが WIDE だった らクライアントも WIDE しゃないといけないの ? monkey : いや。 DHCP の機能やらプロトコル自体は、 RFC2131 ちゅうドキュメントで規定されてるから、そ れに従ったもんやったらどれでも DHCP サーバーや クライアントになれる。 あつぶる : なるほどね。だから Windows 95 を DHCP クライアントにしてもうまくいくんだ。 monkey : そういうこと。 あつぶる : しゃあ、さっそく試そうよ。 monkey : もうちょっと待ってや。ちょいと確かめなあ かんことがあるんや。 : なんでや ! : そのほうがあとの楽しみが大きくなるやろ ? あっぷる : またじらしちゃって・・ monkey monkey UNIX MAGAZINE 1997.7 カーネルの冓築 DHCP サーバーの準備はここまでの作業で終了しまし たが、まだすこし準備が必要です。 FreeBSD2.1.7 では、 このままでは DHCP サーバーは起動しません。 DHCP サーバーを立ち上げても、たとえば次のようなメッセージ が /var/log/messages に出力さ正常に起重丿、きませ ん。 May 19 16 : 02 : 57 umpc dhcps [ 5616 ] : can 't open bpf in open-if ( ) その理由は、デフォルトのカーネルに bpf (Berkeley packet Filter) という仮想デバイスが用意されていない ためです。 WIDE-DHCP では、 bpf を利用して DHCP サーバーを動かすので、これがないと起動しないのです。 ここでいうカーネルとは、 UNIX システムの中枢となる プログラムで、 /kernel というファイルがこれにあたり ます。あるデバイスを新規に利用しようとしても、カーネ 41

8. UNIX MAGAZINE 1997年7月号

連載倉敷芸術科学大学のネットワーク構築ー① 認証ゲートウェイ ます。 セキュリティについては、さらに次のような晒があり 異なるノート PC ューサーに割り当てられるので、アドレ の関係がなりたっているあいだは、 1 つの IP アドレスが ノート PC のユーザー数 > 情報コンセント数 情報コンセントぶんのアドレスが必要です。 全ューサーが同時に使えるようにするためには、すべての 接続ポイントとして情報コンセントを利用するとします。 倉敷芸利大を例に考えてみましよう。ネットワークへの ます。 は逆にアドレスを必要以日こ消費してしまうこともありえ ースの有効利用があります。しかし、運用形態によって DHCP を推奨している理由の 1 つに、アドレススペ IP アドレスの枯渇 からのアクセスしか許可しないメカニズムが必喫です 2 よって正しく割り当てられたアドレスをもつクライアント あいだに認証ゲートウェイを設けて、 DHCP サ→ヾーに するネットワークと、守る必要のあるネットワークとの これらの問題に対応するには、 DHCP サーピスを提供 対応できません。 このようなケースに対しては、割当て時の認証だけでは する。 クを流れるバケットをタップしてアドレスを不正に入手 ・ tcpdump コマンドなどを利用し、接続するネットワー スを有測限が過ぎても使い続ける。 過去に DHCP サ→ヾーから割り当てられた IP アドレ しかし逆に、 スか有効に利用できます。 76 2 私ク刈移寸象だったりします。「 Inet'97 」をお楽しみに ; ー ) 意されています。情報コンセントの先にハプやスイッチが 倉敷芸科大では、約 1 , 000 カ所に情報コンセントが用 クティビティを提供することかできません。 意しなけれは、すべての場所で平等なネットワーク・コネ の状態になると、情報コンセントの数だけのアドレスを用 情報コンセント数 > ノート PC のユーサー数 つながっているところもあるので、比較的多くのアドレス スペースが必要になります。教室など、特定の時間しか利 用しない部屋でのアドレススペースの確保は、 IP アドレ ス窈曷を早める要因になりかねません。 複数の DHCP サーバーかある場合 同しセグメントに対し、複数の DHCP サーバーでサー ピスを提供する場合には、割り当てるアドレスの重複など に注意する必要があります。 複数の DHCP サ→ヾーで同じサーピスを同時に提信い一 ると、サーバーの不頁によっては、各サーバーが別々のク ライアントに同しアドレスを割り当ててしまうこともあり ます。一方、発信したホストのアドレスなどの情報をネッ トワークを流れるデータから自重加勺に取得し、重複を避け て割り当てるサーバーもあるようです。 アドレスの割当て状況を見するようなサーバーがあれ は、まったく同しアドレスプールを割り当てて、 DHCP サ→ヾーのバックアップとして利用することかできます。 DHCP サーパーの安定性 DHCP により割り当てられたアドレスには有測限が 設定されています。そして、有期限が迫ってくると、ア ドレスの再割当てをおこないます。もし、このときサーバ ーか応答しなければ、クライアントのコネクションは切断 されてしまいます。 DHCP サーバーの安定は、基幹業務や研究における 基本的なインフラストラクチャとしてきわめて重要なポイ ントです。 アドレスの再割当て DHCP サーバーは、クライアントからの要求に応えて アドレスを割り当てる際に、以前にそのクライアントに割 り当てたアドレスを優先して割り当てようとします。なか には、たとえ別のアドレスカ」り当てられる場合でも、以 前に割り当てたアドレス以外は割り当てないサーバーもあ ります。アドレスの有抔リ用という観点からいうと、これ は悲しい仕様てす。たしかに、同一ホストに対して同しア ドレスを割り当てたはうがよいこともありますが、なんと かしてほしいところです。 UNIX MAGAZINE 1997.7

9. UNIX MAGAZINE 1997年7月号

連載 IJN Ⅸ知恵袋ーの ときと同様です。すなわち、サブドメインを管理するネー は 10 / 8 の名前空間に関する権限をもっていないからで ら権威つ、けなければなりません。なぜなら、 ns. foo ・ co ・ jp たとしましよう。そのような場合には、ルートサーバーか 133.159 / 16 に含まれない名前空間を利用する必要が生じ 次は変更が必要な場合です。たとえば、 10 / 8 という せん。 は、 ns. foo. co. jp カ材威づけすればよいので間題はありま ば 133.159.48 / 24 を管理するネームサーバーを作るとき 理しています。 133.159 / 16 に含まれる名前空間、たとえ の例では、 133.159 / 16 の名前空間を ns. foo. co. jp か着 ます、変更しなくてもよい場合をみてみます。さきほど 関する言殳定を変更する必要があるかもしれません。 逆引きを設定するときは、ルートサ→ヾーの権威づけに います。 ムサーバーを用意して、 ns. foo. co. jp カ材雀威づけをおこな す。 メールをやりとりすることはできません。 の言 t 算機とインターネット」 :. の言算機のあいだでは、直接 通常、ファイアウォールで防御されたネットワーク内 MX レコードの設定 66 境界に位置する計算櫞、 3. 外部言 t 算機から内部言算櫞へ 境界に位置する計算機・、、 2. 内部言 t 算機から外部言算機 " 、、 妾通信 1. 内部言算機から内部言算、 はよいことになります。 を構築している場合には、次のようにイ乍する設定にすれ foo. co. jp がファイアウォールで守られたネットワーク 該当する計算機に送ります。 ん境界に位置する計算機が受け取り、内部ネットワークの ターネットから内部ネットワークへのメールも、いった ネット上にある相手の計算機に送られます。逆に、イン いったん境界に位置する計算機に渡したあとに、インター 内部ネットワークからインターネット宛へのメールは、 には、メールの酉占逶を次のように設定します。 しかし、それではひどく不便てす。この問題を解決する 図 6 内部ネットワークの MX の IN MX 10 mailsrv—int . f00. co ・」 p ・ * . co ・」 p. IN MX 10 mailsrv—int . f00 ・ co ・ jp ・ 4. 境界の計算機 外部宛メールは外部へ内部宛メールは内部へ 1 および 2 の設定は、内部ネームサーバーの MX レ コードを用いて実現します。 3 の設定は、外部に公開して いるネームサーバーの MX レコードを用います。 4 だけ は、 MX ではどうしようもないので別のガ去を考えます。 ただし、 DNS のバケットを j 面させるようにファイア ウォールを設定している場合、すなわち DNS に関して は、インターネットと直孑妾続されているネットワークで は MX の設定のみで 4 を実現することも可能です。今回 は DNS を遮断しているネットワークを考えていますか ら、そのガ去は割愛します。 UNIX MAGAZINE 1997.7 ファイアウォールーヒでメールサーバーを動すといった橢及も可能です。 1 ファイアウォールを UNIX ワークステーションでオ友している場合は、 と呼ぶことにします。 f00. co. jp 、外部メーノレサーノヾーを mailsrv-ext. f00. co ・ JP 以降の説明では、内部メールサーバーを mailsrv-int. するよう設定します 1 。 は、外部と内部のメールサーバー間の SMTP 接続を許可 とりカきるように設定しなければなりません。具イ勺に ファイアウォールは、この 2 台のあいだでメールのやり ーバーのあいだでは通信が必喫になります。したがって、 当然のことながら、外部メールサーバーと内部メールサ " と呼びます。 ルサーバーとの通信も可能です。これを、、内部メールサー う 1 台は内部言 t 算機と茁妾通信ができて、かっ外部メー す。以後これを、、外部メールサーバー " と呼びます。も 内部ネットワークにあるメールサ→ヾーとも通信かできま は、インターネット上の言算機と直接通イ言ができて、かっ ワーク側に置きます。インターネット側のメールサーバー す。 1 台をインターネット側に、もう 1 台を内部ネット トワークの境界に 2 台のメールサ→ヾーを置くとイ反定しま 今回の設疋では、メールの酉己医を実現するために、ネッ ネットワークの構成

10. UNIX MAGAZINE 1997年7月号

2. 管理者は、空いている IP アドレスを割り当てる。 3. さらに、 NIS や DNS といったデータベースに登録し、 ューザーに情報を伝える。 4. ューサーは、管理者に割り当ててもらった IP アドレス やホスト名を自分のコンピュータに設定する。 世間では猫も杓子もモーバイルの呪文を唱えている昨 今、こんな面倒を誰もかⅢ・んして受け入れ続けるわけがあ りません。なんとかモーバイルホスト ( 移動州末 ) をサポ ートする仕組みを実現しようという流れになりました。そ して、どこでも接続するだけで IP アドレスやネットマス クなど、ネットワーク接続に必要な情報を自重加勺に設定し てくれる仕組みか考案されました。それがこれから紹介す る DHCP (Dynamic Host Configuration Protocol) です。 DHCP は RFC2131 で規定ささまざまな実装 があります。 DHCP を導入すると、さきほどのネットワーク接続手 順か次のようになります。 1. コンヒュータをネットワークに接続する。 2. DHCP サーバーが自重加勺にネットワーク情報を教えて くれる。 3. つないだコンピュータは教えられた情報どおりに自重加勺 に設定する 28 このように、まったくといっていいほど管理者あるいは 利用者の手を煩わすことがなくなります。 DHCP か取り決められるまでは、 BOOTP (BOOT- strap Prot ocol ) や RARP (Reverse Address Reso- lution protocol) といった仕組み 29 カリ用されていまし た。これらは、 X 端末やディスクレス・クライアントと呼 はれるディスクをもたないコンピュータを、ネットワーク に接続して利用するために用いられています。このイ督はみ を使っても、基本的なネットワーク接続情報 ()P アドレ スやネットマスクなど ) の自動設定は可能です。しかし、 それ以上は無理でした。一方、 DHCP はこれらの仕組み と」 : 位互換を保ちながら、さらに多くの情報を自咸定す 32 ルや市販の書籍などを参考にしてください。 29 こでは詳しく説明できませんが、興一ゞあれまオンライン・マニュア 28 このあたりの詳しい信齟みはします。 ることかて、きます。 DHCP がどのようなイ督はみで、何がおこなわれるのか をもうすこし詳しく説明します。かならすしも憶えておく 必要はありませんが、トラブルに見舞われたときなどの手 掛かりにはなるでしよう。 DHCP の概要 DHCP は、、サー ・クライアントシステム " を採用 しています。ネットワーク上には DHCP サーバーと DHCP クライアントか存在し、サーバーはクライアント からの要求に従ってサービスを提供します。それぞれの役 目を簡単に説明すると、次のようになります。 ・ DHCP サーパー : クライアントに提供するデータをも ち、クライアントからの要求に対してネットワーク接続 情報を提供する。 ・ DHCP クライアント : サーバーにネットワーク情報の 提供を要求し、サーバーからの情報を受けて自分のネッ トワーク竟を設定する。 もうすこし詳しく説明しましよう。以下は、図 20 を参 照しながら読んでください。 DHCP サーバーは、ネットワークにシステムカ鮟続さ れた際に必要となるさまざまな設定情報をもっています。 、 NIS サーバー、 NTP サーバーなどの ・デフォルト・ゲートウェイなどの通信情報 ネットマスクなどのインターフェイス情 DHCP サーバーカ甘是供できる情報には、以下のようなも ・ DNS サーノ、 報 ・ IP アドレス、 のがあります。 UNIX MAGAZINE 1997.7 ライアントは、受け取った情報をもとにネットワーク・イ しているネットワーク接続報を提供します。 DHCP ク ます。この要求に対して、 DHCP サ→ヾーは自分か管理 と、接続のために必要な情報を DHCP サーバーに要求し ワークに DHCP クライアントが ( 物理的に ) 接続される ットワーク接続に必要な情報をもっていません。ネット 続されるさまざまなシステムに載っています。これらはネ これに対し、 DHCP クライアントはネットワークに接 に管理する必要があります。 管理者は、 DHCP サーバー上のこれらの情報を、適切 サーバー情報