第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ルータの作成 （2010/2/9）
natテーブルを用い、市販のブロードバンドルータと同等かそれ以上の機能を備える「Linuxルータ」を作成してみましょう - Web監視機能を賢く利用する （2010/2/2）
プロセスの稼働確認だけでは、サービスが正常に提供できているか分からないことも。そこで使いたいのがWeb監視です - ものいわぬOpenLDAPサーバのログ管理 （2010/1/20）
不満をいわないコンピュータが相手だからこそ、常にログが確認できる状態を整備することが重要になります - ネットワークアクセス権も放棄せよ （2010/1/12）
新しいセキュリティ機構「disablenetwork」を提案する1通のメールから始まった議論が、LSMも巻き込む話へと拡大しました
 |
|
|
|
|
スキルアップ／キャリアアップ（JOB@IT）
スポンサーからのお知らせ
- - PR -
- - PR -
お勧め求人情報
*＊先週の人気講座ランキング＊*
〜CCNA編〜
| ◆ | 企業の仮想化に足りない“発想”とは？ 仮想化運用管理のキモは意外なところに！ New！ |
| ◆ | 操作もマニュアルも分かりやすい！ ユーザー視点で開発されたPC管理ツール New！ |
| ◆ | 仮想化すればコストは削減できるか？ 仮想化に必要な「3つの視点」を解説する |
| ◆ | セキュリティを知り尽くす上野氏が登壇！ ＠ITメールソリューションLive! in Tokyo |
| ◆ | 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは？ |
| ◆ | 世界に通用するストレージの作り方とは？ 製品に込めた思いを富士通の開発者に聞く |
| ◆ | OSSで手間も時間も、障害も減った―― 「マピオンの事例」オープンソース活用法 |
| ◆ | 「ノートPCの持ち出し禁止」で大丈夫？ 情報漏えいを防ぐ管理手法とインフラは？ |
| ◆ | 1日の処理を1秒に――MySQLの達人が語る 「コスト削減」できるチューニング |
| ◆ | ドキュメント作成を自動化して、SEの作業 効率を大幅アップ！ Visio 2007の魅力 |
| ◆ | 急速に広がるHyper-Vでのサーバ仮想化 そのベストプラクティスをデルが解説 |
| ◆ | ＠IT主催セミナーで語られた、「担当者に 求められるセキュリティ対策」をレポート |
| ◆ | ＠IT「Windows 7」 特設サイトオープン！ 最新情報・移行ノウハウを公開しています |
著作権はアイティメディア株式会社またはその記事の筆者に属します。（著作権について）
当サイトに掲載されている記事や画像などの無断転載を禁止します。
「＠IT」「＠IT自分戦略研究所」「＠IT情報マネジメント」「JOB＠IT」「＠ITハイブックス」「＠IT MONOist」「ITmedia」「誠」「BARKS」は、アイティメディア株式会社の登録商標です。
当サイトに関するお問い合わせは「＠ITへのお問い合わせ」をご覧ください。