BINDにはフォワードという機能があります。

DNSサーバは自分で返答できない問い合わせ(つまり、自分が権威を持っていないゾーン」の問い合わせ、およびキャッシュも持っていないレコードの問い合わせ)を受けた際、通常であれば再起問合わせを行ないます。

それに対してフォワード機能は、「自分で返答できない問合わせが来ると他のDNSサーバに問合わせを行なう」という機能です。

フォワードされたDNSサーバが再起問合わせを行い、その結果をフォワードしてきたDNSサーバに返します。


再起問合わせを行なう場合、何度も回線を往復することになります。この回線がボトルネックとなるようなケースの場合、フォワードを利用することで回線に負担をかけずに済みます。


options {
        directory "/var/named";

        (省略)

        forwarders {回送先のDNSサーバのアドレス;}; (1)
        forward only; (2)
};



(1)回送先のDNSサーバのアドレスを指定します。
(2)forward only を設定すると、再起問合わせを利用しなくなります。

回送先のDNSがダウンしていた場合などで利用できない場合、自分で再起問合わせを行なうようになりますが、forward only を設定すると、再起問合わせを利用しなくなります。

forward を利用する場合は、障害時のときを考えて複数指定しておくのが良いでしょう。






本日はココまで。
本日のポイントは以下のとおり!

・フォワード機能は、「自分で返答できない問合わせが来ると他のDNSサーバに問合わせを行なう」という機能。
・フォワード先のDNSがダウンしていた場合、自分で再起問合わせを行なうようになる。
・forward を利用する場合は、障害時のときを考えて複数指定しておくのが良い




named.conf の基本原則は、全体の設定(デフォルトの設定)はOptionステートメント内に記述する、個々のzoneの設定はzoneステートメント内に記述するです。

例えば、以下の様にoptionステートメントとzoneステートメントに「allow-query」の設定を記述したとします。

options {
        directory "/var/named";

        (中略)

        allow-query { any; };

        (中略)

};

        (中略)

zone "dns-test.com" {
        type master;
        file "localhost.zone";
        allow-query { 127.0.0.1; };
};



optionステートメントに「allow-query」がany となっているため、原則として全てのホストからの問い合わせを許可することになります。しかし、"dns-test.com"のzoneステートメントに「allow-query」が127.0.0.1 となっています。この場合、dns-test.com のゾーンに対しては127.0.0.1以外のホストからの問い合わせは拒否する、ということになります。


本日はココまで!

覚えておく事項は、
named.conf の基本原則は、全体の設定(デフォルトの設定)はOptionステートメント内に記述する、個々のzoneの設定はzoneステートメント内に記述するです。

今回はSOA(Start of Authority)レコードの詳細について説明します。

以下はSOAレコードの例です。
 dns-test.com.     3600    IN SOA  ns1.dns-test.com.  root.dns-test.com(
                                 
                                  2003031401      ; Serial   
                                  3600            ; Refresh   
                                  900             ; Retry    
                                  604800          ; Expire   
                                  3600 )          ; Minimum   


はゾーン名を表します。ここで指定したゾーンの権限を持つことを宣言します。
はこのゾーンのマスターDNSサーバを指定します。
はこのゾーンの管理者のメールアドレスを指定します。@マークが「.」に置き換えられます。
この例の場合、root@dns-test.com となります。
※@マークは別の意味で使われるため使用できません。

はシリアルナンバーを表します。数字が大きいほど新しいゾーンファイルであると見なされます
基本的に日付と更新した回数で記述されますが、縛りはありません。ただし、ただの通し番号だといつ更新したのか解らなくなるため、管理がしづらいという欠点があります。

スレーブサーバはこのシリアルナンバーの値を参照し、これが自分の持っているゾーンファイルよりも大きいときのみゾーン転送を行ないます。従って、シリアルナンバーを更新し忘れたり間違えてしまうとゾーン転送が正しく行なわれなくなります。

Refreshはスレーブサーバがマスターサーバに対してゾーンファイルの確認を行なう時間の間隔を指定します。スレーブサーバはここで指定した時間が経過すると、ゾーンファイルが更新されているかどうかを確認し、もし、シリアルナンバーが大きくなっていたら(更新されていたら)ゾーン転送を行ないます。
この数値はあまりに短いと、それだけネットワークへの負担が大きくなります。逆にあまりに長いとゾーンファイルの更新が行なわれたときにその変更がスレーブサーバに反映されない、ということになります。最長でも「86400」(24H)としておきましょう。

RetryはRefreshがネットワークトラブルなどにより上手くいかない場合に再度確認の試行を行なうまでの時間となります。RetryはRefreshの数分の1、refreshの値の大小にあわせて120から7200程度に設定するのが一般的です。

ExpiryはRefreshがネットワークトラブルなどにより上手くいかない場合に、そのゾーンに関する情報を無効と見なすまでの時間です。無効と見なすと、そのゾーンに関する問い合わせには応答しなくなります。
Expiryは短すぎると些細なトラブルでも名前解決ができなくなってしまいます。逆に長すぎるとトラブル発生時に誤った情報が放置されることになります。一般的にExpiryは2週間から数週間程度に設定します。
ちなみにExpiryに指定した時間が経過してしまいゾーンに関する情報が無効となってもゾーンファイル自体はスレーブファイルに残ります。したがって、万一、マスターサーバがクラッシュしてしまった場合などにも、スレーブサーバに残ったゾーンファイルを元にマスターサーバを復旧したり、スレーブサーバをマスターサーバに昇格させることが出来ます。

MinimumはネガティブキャッシュのTTL値を表します。
ネガティブキャッシュとは問い合わせたレコードが存在しなかった場合に「問い合わせたレコードは存在しない」という情報をキャッシュする機能です。この値をあまり長くすると新しいレコードを追加したときに、その情報がなかなか引けなくなるという事態が起こってしまいます。ネガティブキャッシュの値は最大で10800(3時間)となっています。ここの値はあまり長く設定せず、900~3600程度に設定しておくと良いでしょう。


本日はココまで!

今回の講義で覚えておいてもらいたい事項は以下のとおりです。
①スレーブサーバはマスターサーバのSOAレコードのシリアルナンバーが自分のゾーンファイルのシリアルナンバー値より大きいかどうかでゾーン転送するかどうかを判断する。
②なのでゾーンファイルを更新した後はシリアルナンバーを必ず更新しておく必要がある。
③SOAレコードのRefresh、Retry、Expire、の意味を理解する。
④ネガティブキャッシュは問い合わせたレコードが存在しなかった場合に「問い合わせたレコードは存在しない」という情報をキャッシュする機能。
⑤ネガティブキャッシュのTTLが長すぎると、新しいレコードを追加したときに、そのレコードの情報が引けないという事態が起こる可能性がある。





↑このページのトップヘ