 |
| 5 セカンダリDNSサーバのインストール（BIND for NT） |
|
あらためてDNSサーバとは DNSサーバの構築で説明したように、ドメインの中には、そのドメインを担当し、責任を持って名前の解決をするDNSサーバが必要です。このDNSサーバは、ネットワークのサービスの中でもとりわけ重要で、このサービスがじゅうぶん機能していないと、Webサーバも、メールサーバも支障をきたしてしまいます。Webサーバへのアクセスも、メールサーバへのアクセスも、実際には、そのサーバのIPアドレスを指定することでアクセスすることはできますが、インターネット側からやってくる一般のお客さんは、サーバのIPアドレスなど知らないわけですから、DNSサーバがいかに重要かは、もうおわかりだと思います。 そんな重要なDNSサーバですが、コンピュータ上で稼動しているかぎり、障害を完全にまぬがれるわけにはいきません。そのため、DNSサーバに障害が発生した場合、そのDNSサーバにかわって、DNSのサービスを行なうバックアップの仕組みが必要です。いわゆるセカンダリDNSサーバです。これに対して、バックアップされるメインのDNSサーバをプライマリDNSサーバと呼びます。 ここで説明しているネットワーク構築の中では、プライマリDNSサーバは自分たちで設置していますが、セカンダリDNSサーバはOCN側で用意してもらうことになってはいます。セカンダリDNSサーバがバックアップのためのものであることを考えれば、プライマリDNSサーバとセカンダリDNSサーバは、物理的にも論理的にも距離があったほうが、そのリスクの分散という目的にかなっています。 （しかし、現実的に考えて、サーバが何台もあって、DNSのサービスとメールサービス、Webサービスなどをサーバごとに分担しているような大規模ネットワークならともかく、1台だけのインターネットサーバしかなく、そのサーバ上でDNSもメールもWebも稼動させているというような場合、とくにWindowsNT上で稼動させている場合、DNSのサービスだけがダウンしているようなケースは少なく、そのマシンそのものがダウンしているケースのほうが多いでしょう。そんなときに、外部にセカンダリDNSサーバが稼動していても、どれほど意味があるものかは、正直なところ疑問です。暴論かもしれませんが...） セカンダリDNSサーバをOCN側で用意している場合には、あらためてセカンダリDNSサーバを構築する必要はありません。しかし、セカンダリDNSサーバには、プライマリDNSサーバがダウンしたときのバックアップDNSサーバとしての役割とは別に、プライマリDNSサーバが過負荷になったとき、プライマリDNSサーバにかわってDNSのサービスを提供するという重要な役割も持っています。 たとえば、Windows98では、「DNSサーバーの検索順」としていくつかのDNSサーバを設定することができます。通常、一番上にプライマリDNSサーバを、2番目以降にセカンダリDNSサーバを設定します（かならずしも、プライマリ-->セカンダリの順番にしなければならないわけではありません）。そのため、OCN側のセカンダリDNSサーバとは別に、さらにもう1台のセカンダリDNSサーバを構築してもかまいません（ただし、この3台目のDNSサーバは、上位のDNSサーバに登録されないかぎり、公式には存在が認められないため、プライマリDNSサーバがダウンしたときには、外部からのアクセスに対しては、バックアップとして機能できません）。 セカンダリDNSサーバがなん台あってもかまわないのと同じように、プライマリDNSサーバも1台しか存在できないわけでもありません。ひとつのドメインに複数のプライマリDNSサーバがあってもかまいません。ただし、上位のDNSサーバに登録できるプライマリDNSサーバは1台だけであるため、2台目以降のプライマリDNSサーバは、勝手に「自分はプライマリDNSサーバだ」と主張しているだけのプライマリDNSサーバで、現実問題としては、内部ネットワークから参照されるだけのプライマリDNSサーバとなるでしょう。 また、1台のプライマリDNSサーバは、ほかのドメインのプライマリDNSサーバにも、ほかのドメインのセカンダリDNSサーバになることもできます。同様にして、1台のセカンダリDNSサーバは、ほかのドメインのプライマリDNSサーバにも、ほかのドメインのセカンダリDNSサーバになることもできます。OCN側のセカンダリDNSサーバも、何台ものDNSサーバが設けられているわけではなく、1台（物理的には複数台かも知れませんが）のDNSサーバで複数のドメインのセカンダリDNSサーバになりえているものと思われます。 さて、ここでは、BIND for NTによって、内部ネットワーク（ここでは、まだセグメントが分かれていません）内にセカンダリDNSサーバを設ける方法と、ちょうどOCN側にセカンダリDNSサーバを設けるのと似たかっこうで、すでにひとつのドメインのプライマリDNSサーバであるDNSサーバに、別のドメインのセカンダリDNSサーバを兼任させる方法を説明します。たとえば、知人のネットワーク内のプライマリDNSを自分のドメインのセカンダリDNSサーバとなってもらうわけです。もちろん、知人のネットワーク内にあるセカンダリDNSサーバに自分のドメインのセカンダリDNSサーバも兼任してもらうこともできます。 BIND for NTをセカンダリDNSサーバとしてインストール セカンダリDNSサーバをインストールする前に、プライマリDNSサーバがきちんと動作しているか、当然、セカンダリDNSサーバ側からプライマリDNSサーバ側にアクセスできなければなりません。IPアドレスの設定などを確認しておいてください。また、プライマリDNSサーバ側の「named.boot」ファイルの「xfrnets」行で設定してあるゾーン転送への制限の対象外に、セカンダリDNSサーバがなっていなければなりません。以上のことを確認したらインストールの開始です。 セカンダリDNSのインストールは、プライマリDNSのインストールと基本的には、変わりません。ただし、インストール途中に表示される「Primary DNS」「Secondary DNS」「Cashing only DNS」の選択で、「Secondary DNS」（デフォルト）を選択します。
また、インストールの最後のステップで「Please enter the IP address of the DNS from which you will RECEIVE zone transfer (your primary)」という入力ダイアログボックスが表示されます。メッセージのとおり、ゾーン転送によってソーンの情報を手に入れる（プライマリ）DNSサーバのIPアドレスをここでは入力します。
インストールがすむとプライマリDNSサーバのインストールのときと同じように、6つの設定ファイルができあがります。\var\namedにインストールされる「db.ZONEINFO」「db.inaddr」（dbのあとにネットワークアドレスは続かない）「db.127.0.0」「db.cache」とWindowsNTがインストールされているディレクトリに作られる「NAMED.BOOT」「resolv.conf」です。 プライマリDNSサーバのインストールのときと同じように、いずれもテキストファイルで、エディタなどで編集することができます。デフォルトのままでは、不十分なところがあるため、修正しなければなりません。 内部にセカンダリDNSサーバ WindowsNTディレクトリのNAMED.BOOTファイルでは、修正する個所はあまりありません。
このうち、
ここまでは、そのままにします。「primary 0.0.127.IN-ADDR.ARPA db.127.0.0」の行は、いまインストールしようとしているマシン（のループバック）にとっては、自分自身がプライマリDNSサーバであることを意味しています。
ゾーン転送は制限しなければなりません。ただし、セカンダリDNSにとっては、もうゾーン転送する相手がいないため、許可する相手がいません。
とすれば、自分自身へのゾーン転送しか認めないことになって、結果的にだれからのゾーン転送要求にも応えなくなります。
この2行がもっとも重要な設定行です。まずはじめの行では、このDNSサーバが「hyperdyne.co.jp」というドメインの「secondary」DNSサーバであることが定義付けされています。そしてプライマリDNSサーバとなるマシンのIPアドレス「210.160.79.98」が続き、最後にその設定のためのファイルが「db.zoninfo」であることが定義付けされています。 secondary ドメイン名 プライマリDNSサーバのIPアドレス 定義ファイルの名前 という順番です。インストール中に入力した情報をもとに設定がされているはずです。 先の行が「正引き」（名前からIPアドレスを調べる）に関する設定だったため、次行で「逆引き」（IPアドレスから名前を調べる）に関して設定されています。 secondary 逆引きのドメイン名 プライマリDNSサーバのIPアドレス 定義ファイルの名前 プライマリDNSのときと同じように、「79.160.210.in-addr.arpa」を「76.79.160.210.in-addr.arpa」と修正します。
最後の行はそのままにします。
WindowsNTディレクトリにあるresolv.confは、
となっています。このresolv.confは、いまインストールしようとしているマシンにとって、ドメインがなんという名前で、DNSサーバがどれかを教えるものです。自分自身が自分にとってのプライマリDNSであってもかまいません。ここでは、プライマリDNSをプライマリDNSとして、2番目に自分自身を、3番目にOCN側のセカンダリDNSを設定してみました。
さて、基本的には、セカンダリDNSサーバの設定は以上で終わりです。「db.cache」はプライマリDNSのインストールのときと同じように、もっとも最上位のDNSサーバを指定するもので、最新のものであるかどうかを確認するだけです。「db.127.0.0」は、ループバック用の設定ファイルであり、管理者のメールアドレスを確認するだけです。 さらにプライマリDNSサーバの設定でもっとも重要だった「db.ZONEINFO」「db.inaddr」ファイルですが、BIND for NTの起動時にすでにプライマリDNSサーバからゾーン転送によって情報を得ているはずです。開いて確認してみてください。 外部にセカンダリDNSサーバ 知人のネットワークのプライマリDNSサーバを、自分のネットワークのセカンダリDNSサーバにする方法も、「内部にセカンダリDNSサーバ」の方法と基本的には変わりません。 もしかりに、「xxxx.co.jp」というドメインのプライマリDNSであるとすると、named.bootファイルは、
といったような設定になっているはずです。ここにそのまま書き加えていきます。
このとき、「210.160.79.98」は自分のネットワークにあるプライマリDNSサーバのIPアドレスであることと、知人のネットワーク内のプライマリDNSサーバ側で使うファイルとは違うファイル名を設定することに気をつけます。あとは、そのDNSサーバを再起動すれば、自分のネットワークにあるDNSサーバからゾーン転送して、必要なファイルができあがります。もちろん、自分のネットワーク内のプライマリDNSサーバの「xfrnets」で、知人のネットワーク内にあるプライマリDNSサーバへのゾーン転送を許可しておかなければなりません。 ゾーン転送の確認 セカンダリDNSサーバから、プライマリDNSサーバにゾーン転送のテストをすることもできます。BIND for NTには、「xfer」というコマンドがあるので、DOSプロンプトで、次のように入力し実行します。 xfer -z （ゾーン転送したいドメイン名） -f （ファイル名） -s 0 （プライマリDNSのホスト名） （-zなどのオプションのあとに半角スペースを入れる。ここではプライマリDNSサーバを対象にするが、相手がDNSサーバであって、ゾーン転送が許可されたマシンからならなんでもいい） たとえば、 xfer -z hyperdyne.co.jp -f hyperdyne.zoneinfo -s 0 ns とか xfer -z hyperdyne.co.jp -f hyperdyne.zoneinfo -s 0 ns.hyperdyne.co.jp とすると「hyperdyne.zoneinfo」という名前のテキストファイルができているはずです。このとき「-s 0」はシリアルナンバー「0」以上といった意味になるようです。 xferコマンドは、BIND for NTがインストールされているディレクトリにいっしょにあり、最初にMS-DOSプロンプトを開いてから、xferアイコンをドラッグ&ドロップするとめんどうがありません。 UNIX環境の場合は、「named-xfer」コマンドを使って、 /usr/sbin/named-xfer -z hyperdyne.co.jp -f /home/oohashi/hyperdyne.zoneinfo. -s 0 ns.hyperdyne.co.jp といったように実行します。 逆引きのゾーン転送は、 xfer -z 96.79.160.210.in-addr.arpa -f hyperdyne.inaddr -s 0 ns.hyperdyne.co.jp というように、逆引きで設定したゾーン名を指定して実行します。 こうしてプライマリDNSサーバ側からゾーン転送できるかどうか、セカンダリDNSサーバ側からすべて禁止されるかどうかなどをテストします。
|
|||||||||||||
 |
|||||||||||||
|
(C) 1998 HyperDyne Inc.
|
