(1/2)名前解決の速度向上に有効なのがキャッシュサーバ。クライアントにもキャッシュ機能があるため、どこにどのようにキャッシュされるのかを理解していないと問題解決に手間取ることになる。});第1回で、DNSには2種の働きがあるとお話ししました。1つは前回紹介したゾーンサーバ、もう1つは今回紹介するキャッシュサーバです。外向きの仕事をするゾーンサーバに対し、内向きに名前解決の手段を提供するキャッシュサーバは、ユーザーにとって最も身近なDNSです。クライアントがDHCPでIPアドレスを取得する際は、同じようにDNSサーバのアドレスを取得します。/etc/resolv.confにはプロバイダや自組織のDNSサーバを指定しますが、そこに指定するのはキャッシュサーバ機能を提供するDNSのアドレスです。指定されたドメインの問い合わせにしか応えない(「そのドメインに権威を持っている」と表現します)ゾーンサーバは固有のドメイン名を持たない組織には不要ですが、キャッシュサーバはあらゆるインターネットサービスの利用を前提にしています。お手ごろなブロードバンドルータにその役目を期待する前に、一度手元のLinuxサーバを見直してみましょう。続いて、後半では逆引き(第1回参照)の仕組みと設定方法を紹介します。クラスC未満での逆引きをどのように実現するか、クラスレスアドレスを受け取った側と委譲する側の両方の観点から見ていきます。冒頭でも触れたように、最近のルータにはDNSキャッシュ機能を内蔵したものが見受けられます。2000やXPにも同じようにDNSキャッシュ機能(注)が包括されているほか、「○速!」と冠の付いたネットワークアクセラレータソフトにはもはや必須の機能の1つです。TIPS:「名前解決のトラブルシューティング(DNSリゾルバ・キャッシュ編)」こうした背景には、DNSの名前解決の高レスポンス化が体感的な通信速度向上に貢献していることが考えられます。キャッシュですから、2度目以降のヒットでなければそれほどの効果はないものの、意外に同じものを引いている確率は高いものです。プロバイダのDNSをいつも使用しているという方は、ぜひキャッシュサーバを立ち上げて体感速度の違いがどの程度か確認してみましょう。クライアント側のDNSキャッシュの仕組みまず、クライアントマシン(その多くはWindowsでしょう)のDNSキャッシュの仕組みを簡単に理解しておきましょう。9でDNSキャッシュサーバを立ち上げても、クライアントのキャッシュメカニズムを理解していないとトラブル解決に手間取ることが予想されます。さまざまなところでホスト名に対する名前解決の結果が蓄えられるために、結果が同期しなくなる可能性があるのです。2000/XPでは、キャッシュにヒットするデータが存在しなかった場合のみDNSへの問い合わせが行われ、DNSからはTTL(キャッシュ生存期限)付きで結果が返されます。2000/XPは、TTLを最大で8万6400秒(1日)までとし、キャッシュに結果を保存します。第2回で紹介した「ドメイン名が存在しないという否定応答」であるネガティブキャッシュについては、TTLを最大300秒にして保存します(注)。注:最大TTLの値はレジストリで定義されており、レジストリを変更することでTTLの調整が可能です。2000/XPがあるなら、次のようにしてキャッシュデータを確認してみましょう。/displaydns」を行えば、待った秒数だけTTLが減っているのが分かります。組織のメールサーバのIPアドレスに変更があり、ある特定のクライアントだけ「メールサーバが見つからない」などのトラブルが生じた場合は、上の方法でDNSキャッシュデータを確認し、もし問題があるようなら以下のようにしてキャッシュデータをクリアします。9によるキャッシュサーバの構築に掛かりましょう。named.confの準備です。......が、すでに大方は第2回で紹介しています。第2回で紹介した事例では、example.jpドメインのゾーンサーバとしての機能とキャッシュサーバの機能を併せ持っていたわけです。ここでは、キャッシュサーバに特化した設定項目を見ていきます。"local.rev";};/etc/named.conf(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を起動あるいは再起動するのみです。startを実行し、起動スクリプトがない場合はnamed.pidを基に再起動または起動します。次に、digコマンドを使ってキャッシュデータを確認します。ns1.i2ts.ne.jp.数秒待ってから、同じようにdigコマンドを発行します。dns1.i2ts.ne.jp.TTLの値が減っていることが分かります。この値が0になるまで、キャッシュデータが参照されます。yes」以外にも有効な設定がいくつか用意されています。2000/XPのDNSキャッシュ機能に触れた際、TTL/ネガティブキャッシュTTLともに、Windows内であらかじめ決められた値で上限を切ることができると説明しました。9で同じことができないわけがありません。9では以下のようにnamed.confファイル中のoptionsステートメントで指定します。(3)};named.confファイルのoptionsステートメント注:(2)の値はdigコマンドによるTTL値の検証のために極端に小さくしています。先ほどのWindowsの場合と同じにするには「86400」になります。(1)はネガティブキャッシュの最大TTLを指定しています。指定がない場合は10800秒(3時間)になります。通常、キャッシュのTTLの最大値は(2)のように指定します。指定がない場合のデフォルト値は604800秒(1週間)です。TTLについては次回以降Lameキーワードとともに説明します。設定を変更したらnamedを再起動し、再度digコマンドでキャッシュデータのTTL値を確認してみましょう。Slammer(注)対策に追われたことと思います。2000サーバが第三者のサーバを攻撃する悪質なもので、加害者とならないことはもちろん、被害者にならない努力も強いられました。Slammer」参照。UDPポートを閉じてしまうというものです。その過程で一部露呈したのが、DNSの使用ポートと1434UDPポートのバッティング(注)でした。注:「SQLワーム対策の副作用で、DNSに問題が生じる可能性」参照。UDPポートだけを使用していると思われがちですが、問い合わせを行うクライアント側では1024以上の任意のUDPポートが使用され、返答を同じポートで待ち受けます。Slammer対策のためのフィルタが働き、DNS応答を受け取ることができなくなってしまうわけです。TCPポートを使用することがあります。ルータなどにフィルタを掛ける際は、こうした挙動にも注意する必要があります。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。