連載
» 2003年03月21日 00時00分 UPDATE

実用 BIND 9で作るDNSサーバ(4):キャッシュ/逆引きDNSの構築と運用 (1/2)

名前解決の速度向上に有効なのがキャッシュサーバ。だが、クライアントにもキャッシュ機能があるため、どこにどのようにキャッシュされるのかを理解していないと問題解決に手間取ることになる。(編集局)

[鶴長鎮一,@IT]

 第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秒にして保存します()。

注:最大TTLの値はレジストリで定義されており、レジストリを変更することでTTLの調整が可能です。

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

C:\>ipconfig /displaydns
         www.atmarkit.co.jp
         ----------------------------------------
         Record Name . . . . . : www.atmarkit.co.jp
         Record Type . . . . . : 5
         Time To Live  . . . . : 28001 ←TTL(キャッシュ生存期限:
         Data Length . . . . . : 4
         Section . . . . . . . : Answer
         CNAME Record  . . . . : atmarkit-www.atmarkit.co.jp
注:数秒待ってから同じように「ipconfig /displaydns」を行えば、待った秒数だけTTLが減っているのが分かります。

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

C:\>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

named.confの編集

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

acl example-net { (1)
        192.168.0.0/27;
        127.0.0.1;
};

options {
        directory "/var/named";
        pid-file "/var/run/named/named.pid";
        recursion yes; (2)
};

zone "." { (3)
        type hint;
        file "named.ca";
};


zone "localhost" { (4)
        type master;
        file "local.zone";
};

zone "0.0.127.in-addr.arpa" { (5)
        type master;
        file "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を起動あるいは再起動するのみです。/etc/init.d/下にnamedスクリプトがあるなら、

# /etc/init.d/named restart

または

# /etc/init.d/named start

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

# kill `cat /var/run/named/named.pid` ←起動のみの場合は不要
# /usr/local/sbin/named -u named ←/usr/local/sbinにインストールされている場合

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

$ dig @127.0.0.1 www.atmarkit.co.jp


;; QUESTION SECTION:
;www.atmarkit.co.jp.            IN      A

;; ANSWER SECTION:
www.atmarkit.co.jp.     86400   IN      CNAME   atmarkit-www.atmarkit.co.jp.
atmarkit-www.atmarkit.co.jp. 86400 IN   A       211.4.250.170

;; AUTHORITY SECTION:
atmarkit.co.jp.         86400   IN      NS      dns1.i2ts.ne.jp.
atmarkit.co.jp.         86400   IN      NS      dns2.i2ts.ne.jp.
atmarkit.co.jp.         86400   IN      NS      ns1.i2ts.ne.jp.

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

$ dig @127.0.0.1 www.atmarkit.co.jp


;; QUESTION SECTION:
;www.atmarkit.co.jp.            IN      A

;; ANSWER SECTION:
www.atmarkit.co.jp.     86373   IN      CNAME   atmarkit-www.atmarkit.co.jp.
atmarkit-www.atmarkit.co.jp. 86373 IN   A       211.4.250.170

;; AUTHORITY SECTION:
atmarkit.co.jp.         86373   IN      NS      dns2.i2ts.ne.jp.
atmarkit.co.jp.         86373   IN      NS      ns1.i2ts.ne.jp.
atmarkit.co.jp.         86373   IN      NS      dns1.i2ts.ne.jp.

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

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

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

options {
        directory "/var/named";
        pid-file "/var/run/named/named.pid";
        recursion yes;
        max-ncache-ttl  300; (1)
        max-cache-ttl   3600; (2)
        lame-ttl        600; (3)
};
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

;; QUESTION SECTION:
;www.atmarkit.co.jp.            IN      A

;; ANSWER SECTION:
www.atmarkit.co.jp.     3600    IN      CNAME   atmarkit-www.atmarkit.co.jp.
atmarkit-www.atmarkit.co.jp. 3600 IN    A       211.4.250.170

;; AUTHORITY SECTION:
atmarkit.co.jp.         3600    IN      NS      ns1.i2ts.ne.jp.
atmarkit.co.jp.         3600    IN      NS      dns1.i2ts.ne.jp.
atmarkit.co.jp.         3600    IN      NS      dns2.i2ts.ne.jp.

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

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

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


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

UDPポートのバッティング()でした。


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

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

       1|2 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。