第4回 キャッシュ／逆引きDNSの構築と運用
名前解決の速度向上に有効なのがキャッシュサーバ。だが、クライアントにもキャッシュ機能があるため、どこにどのようにキャッシュされるのかを理解していないと問題解決に手間取ることになる。（編集局）
鶴長 鎮一
2003/3/21
第1回で、DNSには2種の働きがあるとお話ししました。1つは前回紹介したゾーンサーバ、もう1つは今回紹介するキャッシュサーバです。
外向きの仕事をするゾーンサーバに対し、内向きに名前解決の手段を提供するキャッシュサーバは、ユーザーにとって最も身近なDNSです。クライアントがDHCPでIPアドレスを取得する際は、同じようにDNSサーバのアドレスを取得します。
/etc/resolv.confにはプロバイダや自組織のDNSサーバを指定しますが、そこに指定するのはキャッシュサーバ機能を提供するDNSのアドレスです。あらかじめ指定されたドメインの問い合わせにしか応えない（「そのドメインに権威を持っている」と表現します）ゾーンサーバは固有のドメイン名を持たない組織には不要ですが、キャッシュサーバはあらゆるインターネットサービスの利用を前提にしています。
お手ごろなブロードバンドルータにその役目を期待する前に、一度手元のLinuxサーバを見直してみましょう。続いて、後半では逆引き（第1回参照）の仕組みと設定方法を紹介します。クラスC未満での逆引きをどのように実現するか、クラスレスアドレスを受け取った側と委譲する側の両方の観点から見ていきます。
DNSキャッシュサーバの運用
冒頭でも触れたように、最近のルータにはDNSキャッシュ機能を内蔵したものが見受けられます。ルータに限らず、Windows 2000やXPにも同じようにDNSキャッシュ機能（注）が包括されているほか、「○速！」と冠の付いたネットワークアクセラレータソフトにはもはや必須の機能の1つです。
| 注：Windows TIPS：「名前解決のトラブルシューティング（DNSリゾルバ・キャッシュ編）」 |
こうした背景には、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秒にして保存します（注）。
| 注：最大TTLの値はレジストリで定義されており、レジストリを変更することでTTLの調整が可能です。 |
もし身近にWindows 2000／XPがあるなら、次のようにしてキャッシュデータを確認してみましょう。
C:\>ipconfig /displaydns |
| 注：数秒待ってから同じように「ipconfig /displaydns」を行えば、待った秒数だけTTLが減っているのが分かります。 |
例えば、組織のメールサーバのIPアドレスに変更があり、ある特定のクライアントだけ「メールサーバが見つからない」などのトラブルが生じた場合は、上の方法でDNSキャッシュデータを確認し、もし問題があるようなら以下のようにしてキャッシュデータをクリアします。
C:\>ipconfig /flushdns |
■named.confの編集
Windowsの話はそこそこに、肝心のBIND 9によるキャッシュサーバの構築に掛かりましょう。まずはnamed.confの準備です。……が、すでに大方は第2回で紹介しています。第2回で紹介した事例では、example.jpドメインのゾーンサーバとしての機能とキャッシュサーバの機能を併せ持っていたわけです。ここでは、キャッシュサーバに特化した設定項目を見ていきます。
acl example-net { （1） |
| /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を起動あるいは再起動するのみです。/etc/init.d/下にnamedスクリプトがあるなら、
# /etc/init.d/named
restart |
または
# /etc/init.d/named
start |
を実行し、起動スクリプトがない場合はnamed.pidを基に再起動または起動します。
# kill `cat /var/run/named/named.pid` ←起動のみの場合は不要 |
次に、digコマンドを使ってキャッシュデータを確認します。
$ dig @127.0.0.1 www.atmarkit.co.jp |
数秒待ってから、同じようにdigコマンドを発行します。
$ dig @127.0.0.1 www.atmarkit.co.jp |
TTLの値が減っていることが分かります。この値が0になるまで、キャッシュデータが参照されます。
■キャッシュサーバに有効な設定
キャッシュサーバには、「recursion yes」以外にも有効な設定がいくつか用意されています。先ほど Windows 2000／XPのDNSキャッシュ機能に触れた際、TTL／ネガティブキャッシュTTLともに、Windows内であらかじめ決められた値で上限を切ることができると説明しました。BIND 9で同じことができないわけがありません。BIND 9では以下のようにnamed.confファイル中のoptionsステートメントで指定します。
options { |
| named.confファイルのoptionsステートメント 注：（2）の値はdigコマンドによるTTL値の検証のために極端に小さくしています。先ほどのWindowsの場合と同じにするには「86400」になります。 |
（1）はネガティブキャッシュの最大TTLを指定しています。指定がない場合は10800秒（3時間）になります。通常、キャッシュのTTLの最大値は（2）のように指定します。指定がない場合のデフォルト値は604800秒（1週間）です。（3）のLame TTLについては次回以降Lameキーワードとともに説明します。
設定を変更したらnamedを再起動し、再度digコマンドでキャッシュデータのTTL値を確認してみましょう。
# dig @127.0.0.1 www.atmarkit.co.jp |
|
|
1/2
|
 |
|
||||
|
||||
 |
連載 実用 BIND 9で作るDNSサーバ |
| Linux Squareフォーラム サーバ構築・運用関連記事 |
 |
連載：Heartbeatでかんたんクラスタリング（連載中） オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します |
|
特集：Apache 2.2でWebサイトをパフォーマンスアップ！ 最新安定版Apache 2.2は、何が変わったのか？ 最新のApacheを新機能の使い方とともに解説する |
|
連載：実用 Apache 2.0運用・管理術（全8回） 本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える |
|
連載：実用
BIND 9で作るDNSサーバ（全15回） 本連載では、BIND 9の構築／運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく |
|
連載：実用qmailサーバ運用・管理術（全14回） 本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで |
|
特集：Samba
3.0の全貌 改訂版 Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する |
|
ホワイトペーパー（TechTargetジャパン）
- natテーブルを利用したLinuxルータの作成・2 （2010/3/11）
IPパケットのディスティネーションアドレスを書き換える「DNAT」を使って、透過型プロキシを構築します - 一歩進んだ監視のカスタマイズ （2010/3/3）
スクリプトの実行結果などを取得できるユーザーパラメータを用いて、自分のニーズにぴったり合った監視を実現 - OSSライセンス順守の第一歩 （2010/2/18）
企業として、OSSライセンス違反を犯さないためには、どのような手順が必要か、いくつかアドバイスします - 無視できないフラグメンテーション問題への解答は？ （2010/2/10）
今回は、メモリコンパクション、そしてメモリバリアを発行するシステムコールという2つのパッチについて深く紹介します
 |
|
|
|
|
スキルアップ／キャリアアップ（JOB@IT）
スポンサーからのお知らせ
- - PR -
 |
「いつかは壊れるサーバ」そんな故障に 迅速で安価に手軽に対応する方法とは？ New！ |
 |
「特権ユーザー」の事件を防げ！ 万能権限を持つユーザーの管理方法とは？ New！ |
 |
仮想環境の構築とデータ保護の特効薬？！ 実績と信頼性の高いパッケージで安心運用 |
 |
仮想環境のバックアップもこれまでどおり 「まるごと取ってまるごと戻す」簡単運用 |
 |
おばかアプリ選手権、第４弾開催中！！ ムダにカッコよくてくだらない作品求ム！ |
 |
社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |
 |
その数、なんと400台以上！ グループ内 サーバの「統合管理」によるメリットは？ |
 |
美人!? まあまあ？ 気になる いやし系!! PV急増で「美人時計」がとった手段とは？ |
 |
進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
 |
運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは？ |
- - PR -
お勧め求人情報
*＊先週の人気講座ランキング＊*
〜CCNA編〜
| ◆ | TomcatやJBossなどAPサーバ環境に関する 情報を集約！ “業務”用APサーバ大百科 New！ |
| ◆ | 一気に解説！ 最新のクラスタストレージ 「RAIDを超えたストレージ基準」……など New！ |
| ◆ | クラウド的ユーザー体験の変化は脅威か？ 仮想化技術を使いこなす運用管理術を紹介 New！ |
| ◆ | 上司や部下、部署内メンバーとの情報共有 を“ガラッ”と変えるコラボツールとは？ New！ |
| ◆ | おばかアプリ選手権、第４弾開催中！！ ムダにカッコよくてくだらない作品求ム！ |
| ◆ | 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |
| ◆ | Twitterのアカウントはなぜ突破された？ メールによる新手の攻撃手法とその対策 |
| ◆ | もう仮想化のお試しフェイズは終わりだ！ Hyper-V 2.0が基幹システムも仮想化 |
| ◆ | 美人!? まあまあ？ 気になる いやし系!! PV急増で「美人時計」がとった手段とは？ |
| ◆ | クライアント企業から求められる人材 ⇒IT技術と経営戦略を併せ持つ「戦略家」 |
| ◆ | .NET編集長が実践する「技術情報検索術」 サンプル・コードを簡単に探す“技”は？ |
| ◆ | 業務効率と情報セキュリティ対策を両立！ 手間なく確実に機密情報を守る方法とは？ |
| ◆ | 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| ◆ | 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは？ |
| ◆ | 【CTC事例】約30の基幹システムを統合！ 膨大なバッジジョブを制御した方法は？ |
| ◆ | 仮想化すればコストは削減できるか？ 仮想化に必要な「3つの視点」を解説する |
| ◆ | その数、なんと400台以上！ グループ内 サーバの「統合管理」によるメリットは？ |
著作権はアイティメディア株式会社またはその記事の筆者に属します。（著作権について）
当サイトに掲載されている記事や画像などの無断転載を禁止します。
「＠IT」「＠IT自分戦略研究所」「＠IT情報マネジメント」「JOB＠IT」「＠ITハイブックス」「＠IT MONOist」「ITmedia」「誠」「BARKS」は、アイティメディア株式会社の登録商標です。
当サイトに関するお問い合わせは「＠ITへのお問い合わせ」をご覧ください。