2014年09月

ゾーンファイルはいくつか省略の記述方法があります。

以下は、非省略形のゾーンファイルです。
-----------------------------------------------------------------------
$TTL    10800
dns-test.com.    IN    SOA    ns.dns-test.com.   root.dns-test.com.  (
                2014083001      ; Serial
                43200        ; Refresh
                5400        ; Retry
                3600000    ; Expire
                3600 )        ; Minimum

dns-test.com.    IN    NS    ns.dns-test.com.
ns.dns-test.com.        IN    A    1.1.1.1
www.dns-test.com.    IN    A    1.1.1.3
mail01.dns-test.com.    IN    A    1.1.1.4
mail02.dns-test.com.    IN    A    1.1.1.5
-----------------------------------------------------------------------




「ドメイン名の省略」
つぎに省略形のゾーンファイルを記述します。
-----------------------------------------------------------------------
$TTL    10800
$ORIGIN    dns-test.com.

@            IN    SOA    ns   root  (
                2014083001      ; Serial
                43200        ; Refresh
                5400        ; Retry
                3600000    ; Expire
                3600 )        ; Minimum
@        IN    NS    ns
ns        IN    A    1.1.1.1
www    IN    A    1.1.1.3
mail01    IN    A    1.1.1.4
mail02    IN    A    1.1.1.5
-----------------------------------------------------------------------
どうでしょう。
まず、「$ORIGIN    dns-test.com.」という記述が見られます。この記述がある場合、「@マーク」が記載されているレコードには、ORIGINで定義したゾーン名の値が割り当てられます。

つまり、SOAレコードとNSレコードのところにある@マーク=dns-test.com ということになります。

ついにレコードのドメイン名が全て、「.」で終了していないところに注目して下さい。「.」で終了していない場合は、そのドメインにORIGINで定義したゾーン名の値が割り当てられます。

つまり、Aレコードにはすべて、「dns-test.com.」が追記されます。wwwの場合は、www.dns-test.com、nsの場合は、ns.dns-test.com、ということになります。


「TTLの省略」
また、各レコードのTTLも省略可能です。頭に記載されている$TTLの値が適用されます。つまり、ここでは各レコードのTTLに「10800」を指定したものと同じ事になります。


「レコードの名前フィールドの省略」
レコードを記述する際、一番左側の項目の記述を完全に省略すると、その前のレコードの名前フィールドが適用されます。

例えば以下の様に記述したものと
 dns-test.com.         IN    SOA    ns   root  (
 dns-test.com.         IN    NS    ns
 dns-test.com.         IN    MX    10   mail01

以下の様に記述したものは同じになります。
 dns-test.com.         IN    SOA    ns   root  (
                                IN    NS    ns
                                IN    MX    10   mail01



「$ORIGIN」を省略する」
以下の様に$ORIGINの記述も省略することが出来ます。しかし、これでは、何が省略されているか解らなくなってしまい、ミスの原因になることが往々にしてあるのでやめておきましょう。
-----------------------------------------------------------------------
$TTL    10800
@            IN    SOA    ns   root  (
                2014083001      ; Serial
                43200        ; Refresh
                5400        ; Retry
                3600000    ; Expire
                3600 )        ; Minimum
@        IN    NS    ns
ns        IN    A    1.1.1.1
www    IN    A    1.1.1.3
mail01    IN    A    1.1.1.4
mail02    IN    A    1.1.1.5
-----------------------------------------------------------------------


本日はココまで。
・$ORIGIN の記述で、ゾーン名を省略できる。
・レコードに「@マーク」を記述した場合は、ORIGINで指定したゾーン名がそのまま割り当てられる。
・レコードが「.」で終わっていない場合は、ORIGINで指定したゾーン名が足される。




named.confやゾーンファイルに変更を加えたときは、その変更を反映させるための操作が必要となります。

変更を反映される方法は2つあります。

1つ目は、
「BINDを再起動させる」です。
再起動の際に設定ファイルやゾーンファイルが改めて読み込まれます。この場合、キャッシュに残っていたデータは全て消去されます。

2つ目は、
「設定ファイル・ゾーンファイルの再読み込み」です。
全てのゾーンファイル(ゾーンファイルの指定も可能)とnamed.confが再読み込みされます。
この方法ではキャッシュのデータは消去されることなく変更を反映させることが出来ます。


本日はココまで!

・設定変更を反映させるには、「BINDを再起動させる」方法と、「設定ファイル・ゾーンファイルの再読み込み」方法の2つがあり、前者はキャッシュデータが全てクリアされ、後者はキャッシュデータは消去されない。

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が長すぎると、新しいレコードを追加したときに、そのレコードの情報が引けないという事態が起こる可能性がある。





↑このページのトップヘ