内部ネットワークに名前解決のための DNS を提供する (CentOS 5.5): Linux の使い方

DNS サーバーで再帰問い合わせを有効にする

DNS サーバーには、取得したドメインのレコードを登録して運用する機能と、外部の DNS サーバーに登録されているレコード情報を取得するという 2 つの用途が大別して存在します。

DNS サーバーでドメインを公開するでお話しした方法は、前者の機能を利用した方法になります。Windows 等のクライアント PC に設定されている DNS サーバーは、後者の機能を利用するための DNS を指定している場合が一般的です。

DNS サーバーソフトウェアである BIND では、この 2 つの機能の両方を提供することができるようになっています。

前者の方は常に使えることが前提となっていますが、後者については第三者へ提供すると悪用される恐れがあるため、意識的に有効化しないと使えないようになっています。ちなみに、後者の機能のことを、"キャッシュサーバー" や "DNS 再帰問い合わせ" 等と言います。

今回はこのキャッシュサーバーを CentOS 5.5 に構築してみるということをやってみたいと思います。

BIND のインストール

CentOS 5.5 では、標準では BIND がインストールされていないようでしたので、必要に応じて次のようにしてインストールを行います。

yum install bind

このようにすることで、平成 22 年 12 月 14 日現在、BIND の 9.3.6-4.P1.el5_4.2 をインストールすることが出来ました。

BIND の設定ファイルを用意する

BIND の設定ファイルは、CentOS 5.5 では "/etc/named.conf" に用意する必要があります。ただ、インストール直後にはこのファイルは用意されないようでしたので、最初は自分で作成する必要があります。

この中で、BIND をキャッシュサーバーとして使用するために、 DNS 再帰問い合わせを有効にします。

acl localnet

{

192.168.0.0/24;

127.0.0.1;

};

acl listener

{

192.168.0.1;

127.0.0.1;

};

options

{

version "unknown";

directory "/var/named";

pid-file "/var/run/named/named.pid";

recursion yes;

recursive_clients 400;

allow-query

{

localnet;

};

allow-recursion

{

localnet;

};

listen-on

{

listener;

};

};

zone "."

{

type hint;

file "data/named.cache";

};

BIND では "recursive" という設定を "yes" とすることで、再帰問い合わせを有効化することができます。

ただ、無関係の第三者がこの DNS サーバーで再帰問い合わせを行えるようにしてしまうと、再帰問い合わせを勝手に使って他方のサーバーへ DDoS 攻撃を仕掛けるなどの悪用ができるようになってしまいますので、いくつか制限をかけています。

まず、"allow-query" で "localnet" を設定して、この DNS を利用可能なクライアントを制限しています。

"localnet" というのは、冒頭の "acl localnet" で指定した IP アドレスからのアクセスという意味になります。もし取得したドメインを登録して外部に向けて公開するような場合には、"allow-query" は "any" にするなどしないと、期待した通りに動作しなくなるので注意します。

そして "allow-recursion" でも "localnet" を指定しています。

これにより、再帰問い合わせを行えるクライアントを "localnet" に限定しています。今回は "allow-query" でも "localnet" に限定していますので、敢えてこれを指定する必要はないかもしれないですが、今後 "allow-query" を調整した時に意図しない動作をしないためにも、ここでも明示的に再帰問い合わせを "localnet" に限定しています。

それと、今回は念のため "recursive_clients" として、同時に再帰問い合わせが可能なクライアント数を指定してみました。

既定値は 1,000 だそうで、同時に処理できる再帰問い合わせの数をここで指定した値に制限することができるそうです。これにより、必要以上な再帰問い合わせが行われないようにすることができるそうです。

なお、設定で "view" を使用している場合には、"recursion" や "allow-recursion" は View 事に設定可能ですが、この "recursive_clients" については View 内ではなく、最初の "options" 内でしか指定できないようでしたので注意します。

そして、キャッシュサーバーとして機能させる上で重要なのが、ルートヒントです。

どの外部 DNS サーバーを使用して DNS レコードの検索（名前解決）を行うかを使用するために、"zone" として "." を設定し、その種類を "hint" としています。これを "ルートヒント" といって、ここで指定している DNS を使って、名前解決を行うことになります。

もっとも、今回指定した "data/named.cache" の中身も用意しないことには、正しく名前解決を行うことはできません。

ルートヒントを用意する

現在のインターネットでは、ルートヒントは Inter NIC というところで管理されていますので、ここで公開している情報を入手する必要があります。平成 22 年 12 月 14 日現在、ftp://rs.internic.net/domain/named.cache からそれを取得することができるようになっていました。

そこで、次のようにしてこれを "/var/named/data/named.cache" として保存します。

wget ftp://rs.internic.net/domain/named.cache -P /var/named/data/

ルートヒントは何年かに 1 度更新されるそうなので、適切に運用を続けるためには変更の都度、このルートヒントの内容を更新してあげる必要があります。

ルートヒントの更新を忘れないようにするために、自動更新されるように設定しておくのも良いかもしれません。それについては EZ-NET： DNS のルートヒントを自動的に更新する (CentOS 5.5) に記してみましたので、そちらも参考にしてみてください。

BIND を起動する

設定ファイル "/etc/named.conf" とルートヒントが準備できたら、次のようにして設定内容が正しいかどうかを確認します。

service named configtest

この時 BIND 9.3.6 では、ルートヒントに設定されているファイルがなくても、エラーとして表示されないようでした。

ルートヒントがないまま BIND を起動しようとすると、起動時に [NG] となって "/var/log/messages" に "could not configure root hints from 'data/named.ca': file not found" と記録されるようでした。

また、SELinux が Enforcing で稼働しているシステムでは、SELinux によってルートヒントファイルの読み込みが拒否されて、起動時に [NG] となってしまう場合があるようでした。この場合、ログに "could not configure root hints from 'data/named.cache': permission denied" と記録されるようでしたので、このようなログがあった場合には SELinux の設定を調整する必要がないか確認すると良いでしょう。

SELinux の設定については SELinux の管理スクリプト案などで記していますので、必要に応じて参考にしてみてください。

設定内容に間違いがなければ、次のようにして DNS サーバーを起動させます。

service named start

今後も Linux 起動時に DNS サーバーを自動起動する場合には、次のようにしておきます。

chkconfig named on

これで DNS キャッシュサーバーの設定と稼働が整いました。

キャッシュサーバーの動作を確認する

キャッシュサーバーが正しく動作しているかどうか、次のようにして確認します。

dig @192.168.0.1 www.yahoo.co.jp a

このようにすると、今回設定した DNS サーバー "192.168.0.1" を使用して、"www.yahoo.co.jp" という A レコードを検索するという意味になります。

これで "ANSWER SECTION" として、ドメインに対する IP アドレスを取得することができれば、ルートヒントを使用して再帰問い合わせが行われ、その結果をこの DNS サーバー (192.168.0.1) から取得できたという判断ができます。

なお、dig コマンドのオプションで "+trace" を指定してしまうと、このキャッシュサーバーが正しく設定されているかどうかにかかわらず再帰問い合わせを行った結果が取得されてしまうようでした。

"/etc/resolve.conf" で DNS サーバーを指定しないと、ルートヒント内のサーバーを探すタイミングで、そのサーバーが見つからないというエラーが表示されるので、この感じから察するに、キャッシュサーバーではなく dig コマンド自体が再帰問い合わせを行っているような感じが伺えました。

以上から、キャッシュサーバーの動作テストの際に "+trace" を付けてしまうと、誤った判断につながってしまう恐れがあるので、"+trace" オプションは付けないように気を付けましょう。