BIND 9の改ざんチェックとインストール：実用 BIND 9で作るDNSサーバ（1）（1/3 ページ）
インターネットの基幹技術、DNS。本連載では、BIND 9を使ったDNSサーバの構築／運用方法を解説していく。現場で実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく予定だ。（編集局）
DNSの生い立ちとBINDの誕生
皆さんが数台のPCを立ち上げて小規模なネットワークを構築した場合、それぞれのPC間での名前解決はどのように実現するでしょうか？
名前解決を行わずIPアドレスだけで用を済ますというのも1つの手ですが、多くの方は/etc/hostsファイルにPCのアドレスとホスト名を記述する方法を思い付くと思います。インターネット創世期にも同じ手法が使われていました（注）。
アドミン（注）は、自ネットワーク内のサーバに変更があるとSRI-NIC（Stanford Research Institute's Network Information Center）にその都度届け出ます。SRI-NICは届けのあったものをまとめ、アドミンが利用できるようにHOSTS.TXTファイルとして公開していました。この手法が間もなく破たんすることは、誰もが予想するとおりです。
そこで考えられたのがDomain Name System（DNS）であり、それを実現するBerkeley Internet Name Domain（BIND）です。いまでこそ当然のように使われているDNSですが、つい数年前まではDNSをサポートするシステムの方がまれで、当時はDNSをサポートするためにlibbind.aなどのリゾルバをインストールすることも珍しくありませんでした。
こうしたことは過去の出来事ではなく、UNIXにはファイルで管理されている情報がまだ潜んでいます。例えば、/etc/servicesファイルにはIPポート番号とサービス名の対応が記述されていますが、サービスの定義に変更があったり、新規にサービスが予約されるたびにRFC（http://www.iana.org/assignments/port-numbers）で公開されている情報を基に変更する必要があります。しかし、サービスの定義の更新がそれほど頻繁でないのと、/etc/servicesファイルがそれほど重要ではないため、従来どおり手動でアップデートする手法が続けられています。もし仮に、「Service Name System」なんていうものができると、普段使用するURLも変わったものになるかもしれません。/etc/protocolsファイルもしかりです。
コラム Windowsのhostsファイル
hostsファイルはLinuxなどのUNIX系OSだけのものでなく、Windowsでも使われています。例えば、Windows
XPではC:\WINDOWS\system32\drivers\etcにhostsファイルとlmhostsファイルが存在します。
DNSは、単にこうしたファイルによる管理をネットワークリソースに切り替えただけでなく、「ホスト名のユニーク性」と「管理の分散化」も実現しています。DNSの詳しい仕組みや基本原理は「集中連載：DNSの仕組みと運用（1）」を参照していただくとして、本連載ではBIND 9の実用的な使用方法を紹介していきます。
BINDの働き
DNSは「DNS」として一くくりにされがちなサービスですが、実は2つの働きをしています。
1つ目が、自身のドメイン問い合わせに答えるゾーンサーバとしての働きで、2つ目がWindowsなどのクライアントが名前解決として使用するキャッシュサーバの働きです。BINDは1つのデーモンで2つの機能を提供するため、これら2つが別々のものであるといってもピンとこないかもしれません。それぞれの働きを正しく理解し、これから立ち上げるDNSサーバにどの役割をさせたいのかを整理しましょう。
ゾーンサーバ
自身が所有するドメイン名をインターネットに広報するために必要なサーバです。「広報」という言葉を用いると、外部に対して能動的に働き掛けるように考えてしまいますが、実際には自ドメイン名に対する問い合わせ要求にこたえるもので、動作としては受動的です。「DNSの仕組みと運用（1）」をお読みいただければ、ルートサーバからドメインツリーをたどって手元のゾーンサーバに問い合わせが到達するか理解できると思います。
手元でサーバを立ち上げるにしろ、どこかに委譲するにせよ、ドメイン名を取得してそのドメインを自組織内外のインターネットで引けるようにするにはゾーンサーバが必要です。
また、ドメイン名解決を行う際に用いられるゾーンデータの出所によって、ゾーンサーバはさらに2つに大別されます。
- マスター・ゾーンサーバ（またはマスターサーバ）
オリジナルとなるゾーンデータを所有するサーバです。オリジナルドメインを運用する際には必ず1つ用意します。ゾーンデータは、通常ローカルファイルを基にします。 - スレーブ・ゾーンサーバ（またはスレーブサーバ）
ゾーンデータをマスターサーバから複製して使用します。マスターサーバが停止しているときなどは、ローカルのゾーンファイルを読み込むことも可能ですが、通常はゾーン転送（zone transfer）と呼ばれる手法でゾーンデータを最新なものに保ちます。
データをマスターサーバから複製していることからバックアップとしての働きを期待されがちですが、ドメイン問い合わせに対してバックアップサーバとするかどうかは運用方法により変えられます。また、スレーブ・ゾーンサーバは、何台でも指定することが可能です。
キャッシュサーバ
キャッシュサーバはクライアントから来る名前解決要求にこたえるもので、目的のドメインをリゾルブできるまで、外部のDNSをドメインツリーをたどって再帰検索します。
BIND 9の場合はゾーンサーバの機能も内包しているため、「自身のゾーンデータに該当しなかった場合」という条件が付きます。可能であれば、ゾーンサーバ用のBINDとキャッシュサーバ用のBINDは区別して運用することをお勧めします。
ゾーンサーバが外部からの問い合わせに対する受動的処理だったのに対し、キャッシュサーバは外部のDNSを参照する能動的なものになります。キャッシュサーバは一度問い合わせた情報をサーバ内のキャッシュに保存し、次に同じ問い合わせが来たときに高速に返答することができます。
また、BIND 9では単に問い合わせに成功した情報だけでなく、名前解決できなかったという情報をキャッシュする「否定キャッシュ」（ネガティブキャッシュ）も備えています。これらの問い合わせキャッシュがどれくらいの期間有効なのかも運用には大事な要素になってきますが、そちらについては次回に「TTL」というキーワードとともに紹介します。
DNS関連用語の確認
DNSの役割と同時に、以下の用語についてもここで整理しておきましょう。
- リゾルバ
名前解決と同じ意味で使用しています。 - ルートサーバ
ネームサーバの総元締。現在13拠点で稼働しており、変更される場合もあります。ルートサーバを起点としてドメインツリーが展開されます。ルートサーバ一覧の入手方法は次回で解説します。 - 正引き
ドメイン名からIPアドレスやネームサーバ、メールサーバのドメイン付きホスト名を検索する手順を指します（例：www.atmarkit.co.jp→211.4.250.170）。本連載では、ホスト名をフルドメイン付きで表現することをFQDN（Fully Qualified Domain Name）と表記します。 - 逆引き
IPアドレスからドメイン名を検索する手順を指します（例：211.4.250.170→www.atmarkit.co.jp）。
Copyright © ITmedia, Inc. All Rights Reserved.