キャッシュ／逆引きDNSの構築と運用：実用 BIND 9で作るDNSサーバ（4）（1/2 ページ）

　第1回で、DNSには2種の働きがあるとお話ししました。1つは前回紹介したゾーンサーバ、もう1つは今回紹介するキャッシュサーバです。

　外向きの仕事をするゾーンサーバに対し、内向きに名前解決の手段を提供するキャッシュサーバは、ユーザーにとって最も身近なDNSです。クライアントがDHCPでIPアドレスを取得する際は、同じようにDNSサーバのアドレスを取得します。

　/etc/resolv.confにはプロバイダや自組織のDNSサーバを指定しますが、そこに指定するのはキャッシュサーバ機能を提供するDNSのアドレスです。あらかじめ指定されたドメインの問い合わせにしか応えない（「そのドメインに権威を持っている」と表現します）ゾーンサーバは固有のドメイン名を持たない組織には不要ですが、キャッシュサーバはあらゆるインターネットサービスの利用を前提にしています。

　お手ごろなブロードバンドルータにその役目を期待する前に、一度手元のLinuxサーバを見直してみましょう。続いて、後半では逆引き（第1回参照）の仕組みと設定方法を紹介します。クラスC未満での逆引きをどのように実現するか、クラスレスアドレスを受け取った側と委譲する側の両方の観点から見ていきます。

DNSキャッシュサーバの運用

　冒頭でも触れたように、最近のルータにはDNSキャッシュ機能を内蔵したものが見受けられます。ルータに限らず、Windows 2000やXPにも同じようにDNSキャッシュ機能（注）が包括されているほか、「○速！」と冠の付いたネットワークアクセラレータソフトにはもはや必須の機能の1つです。

　こうした背景には、DNSの名前解決の高レスポンス化が体感的な通信速度向上に貢献していることが考えられます。キャッシュですから、2度目以降のヒットでなければそれほどの効果はないものの、意外に同じものを引いている確率は高いものです。プロバイダのDNSをいつも使用しているという方は、ぜひキャッシュサーバを立ち上げて体感速度の違いがどの程度か確認してみましょう。

クライアント側のDNSキャッシュの仕組み

　まず、クライアントマシン（その多くはWindowsでしょう）のDNSキャッシュの仕組みを簡単に理解しておきましょう。BIND 9でDNSキャッシュサーバを立ち上げても、クライアントのキャッシュメカニズムを理解していないとトラブル解決に手間取ることが予想されます。さまざまなところでホスト名に対する名前解決の結果が蓄えられるために、結果が同期しなくなる可能性があるのです。

　Windows 2000／XPでは、キャッシュにヒットするデータが存在しなかった場合のみDNSへの問い合わせが行われ、DNSからはTTL（キャッシュ生存期限）付きで結果が返されます。結果を受け取ったWindows 2000／XPは、TTLを最大で8万6400秒（1日）までとし、キャッシュに結果を保存します。第2回で紹介した「ドメイン名が存在しないという否定応答」であるネガティブキャッシュについては、TTLを最大300秒にして保存します（注）。

　もし身近にWindows 2000／XPがあるなら、次のようにしてキャッシュデータを確認してみましょう。

　例えば、組織のメールサーバのIPアドレスに変更があり、ある特定のクライアントだけ「メールサーバが見つからない」などのトラブルが生じた場合は、上の方法でDNSキャッシュデータを確認し、もし問題があるようなら以下のようにしてキャッシュデータをクリアします。

named.confの編集

　Windowsの話はそこそこに、肝心のBIND 9によるキャッシュサーバの構築に掛かりましょう。まずはnamed.confの準備です。……が、すでに大方は第2回で紹介しています。第2回で紹介した事例では、example.jpドメインのゾーンサーバとしての機能とキャッシュサーバの機能を併せ持っていたわけです。ここでは、キャッシュサーバに特化した設定項目を見ていきます。

　（1）は第2回で紹介した設定と同じです。皆さんのネットワーク環境に合わせて指定するアドレスレンジを変更してください。キャッシュサーバという用途を考えると、この指定は必須です。キャッシュサーバが外部のネットワークから使用されるのは不本意です。もしファイアウォールやNATボックス内にDNSキャッシュサーバを設置できるのであれば、外部からのアクセスは一切不要にしても構いません。キャッシュサーバ自身が外部に問い合わせることがあっても、外部からキャッシュサーバに対する何らかの接続が発生することはありません。

　次に前回は説明を省略した（2）の指定です。「yes」にすることで、ドメインツリーの再帰問い合わせを有効にします。つまり、外部のさまざまなドメインに対して返答が可能になります。もしゾーンサーバの機能だけを提供するDNSであればここは「no」とし、自身で管理している（権威を持っている）ドメイン以外の応答には答えないようにすべきです。

　以下（3）、（4）、（5）は第2回で紹介したものとまったく同じです。example.jpの順引きや192.168.10.0/24の逆引きの設定は、キャッシュサーバには不要です。

　なお、localhost（127.0.0.1）に関する指定とルートサーバに関する情報はどの場合も欠かせません。

キャッシュデータの確認

　named.ca、local.zone、local.rev、named.pidを第2回同様に準備します。後は、namedを起動あるいは再起動するのみです。/etc/init.d/下にnamedスクリプトがあるなら、

または

を実行し、起動スクリプトがない場合はnamed.pidを基に再起動または起動します。

　次に、digコマンドを使ってキャッシュデータを確認します。

　数秒待ってから、同じようにdigコマンドを発行します。

　TTLの値が減っていることが分かります。この値が0になるまで、キャッシュデータが参照されます。

キャッシュサーバに有効な設定

　キャッシュサーバには、「recursion yes」以外にも有効な設定がいくつか用意されています。先ほど Windows 2000／XPのDNSキャッシュ機能に触れた際、TTL／ネガティブキャッシュTTLともに、Windows内であらかじめ決められた値で上限を切ることができると説明しました。BIND 9で同じことができないわけがありません。BIND 9では以下のようにnamed.confファイル中のoptionsステートメントで指定します。

　（1）はネガティブキャッシュの最大TTLを指定しています。指定がない場合は10800秒（3時間）になります。通常、キャッシュのTTLの最大値は（2）のように指定します。指定がない場合のデフォルト値は604800秒（1週間）です。（3）のLame TTLについては次回以降Lameキーワードとともに説明します。

　設定を変更したらnamedを再起動し、再度digコマンドでキャッシュデータのTTL値を確認してみましょう。

コラム　SQL Slammer対策とDNSの不具合

　2003年1月末辺りは、どこのネットワーク管理者もSQL Slammer（注）対策に追われたことと思います。感染したMicrosoft

SQL Server 2000サーバが第三者のサーバを攻撃する悪質なもので、加害者とならないことはもちろん、被害者にならない努力も強いられました。

注：「管理者のジレンマを突いて爆発的に繁殖したSQL Slammer」参照。

　そこで用いられた対処方法が、SQL Serverで使用される1434 UDPポートを閉じてしまうというものです。その過程で一部露呈したのが、DNSの使用ポートと1434

UDPポートのバッティング（注）でした。

注：「SQLワーム対策の副作用で、DNSに問題が生じる可能性」参照。

　DNSは53 UDPポートだけを使用していると思われがちですが、問い合わせを行うクライアント側では1024以上の任意のUDPポートが使用され、返答を同じポートで待ち受けます。偶然1434ポートが使用されると、SQL Slammer対策のためのフィルタが働き、DNS応答を受け取ることができなくなってしまうわけです。BIND 9では、このほかにもマスターサーバとスレーブサーバ間のゾーン転送に53 TCPポートを使用することがあります。ルータなどにフィルタを掛ける際は、こうした挙動にも注意する必要があります。

図1　DNSが使用するのは53 UDPポートだけではない