2014年09月

BINDのバージョン情報はセキュリティ面から、開示されるべきではありません。

digコマンドを利用すれば簡単にBINDのバージョン情報を調べることが出来ます。

$ dig @dns-test.com chaos txt version.bind

BINDのバージョンを書き換えるには、opitonステートメント内の「version」を以下の様に書き換えます。
options {
	version "Unknown";
};
こうすることで、外部に公開するバージョン情報が"unknown" となります。


本日はココまで!

今回の講義で覚えておいてもらいたい点は以下のとおり

・BINDのバージョン情報は外部に見せないようにすること
・optionステートメントの「version」 を書き換えることで隠蔽することが出来る。


大規模なWEBサイトを運営するときに、複数台のWEBサーバを構築し、各サーバに処理を振り分けることによって負荷を分散することができます。
利用される技術の1つに「DNSラウンドロビン」があります。

DNSラウンドロビンの概念は到って単純です。
複数台のWEBサーバに異なるIPアドレスが振られている状態で同じFQDNを付けるといった方法です。

設定の仕方は簡単です。
ゾーンファイルに同じFQDNのレコードを書けば良いのです。

www.dns-test.com.   1200   IN    A    1.1.1.3
www.dns-test.com.   1200   IN    A    1.1.1.4
www.dns-test.com.   1200   IN    A    1.1.1.5
www.dns-test.com.   1200   IN    A    1.1.1.6


このようにすると、リゾルバからwww.dns-test.comへの問い合わせがあった場合に上から順にIPアドレスを返します。

ラウンドロビンを行なう場合は、各レコードのTTL値を小さくする(数分程度)に設定し、できるだけ頻繁にアクセス先を変更するようにするのが良いとされています。

DNSラウンドロビンはメールサーバでも使用できます。MXレコードに対して行なうことも可能です。この場合は、MXレコードのプリファレンス値を同じ値に設定しておきます。

dns-test.com.    IN    MX  10    mail01.dns-test.com.
dns-test.com.    IN    MX  10    mail02.dns-test.com.

dns-test.com.    IN    MX  10    mail03.dns-test.com.


※DNSラウンドロビンは障害発生時の障害検知が出来ない問題があるので、最近はクラスタリングなどの他の負荷分散方式が使われることも多いようです。



本日はココまで!
覚えておいて頂きたい点は以下のとおり。

・DNSラウンドロビンは、同じFQDNで複数のレコードを書くことで、順番にIPアドレスを返す方法です。

DNSサーバが使用するメモリ量を制限するには以下、3つの方法があります。


1 キャッシュに利用するメモリ量を制限する。

named.confファイルのoptionステートメントに「max-cache-size」を指定します。
キャッシュされたデータ量が指定した値に達すると、新旧問わずキャッシュされたTTLを強制的にゼロ(消去)します。

options {
(省略)
    max-cache-size      60M;
(省略)
};


上記ではキャッシュに利用するメモリサイズを60Mに制限しています。デフォルトでは無制限となっています。



2 キャッシュに残すレコードのTTLを短くする。
TTLの値はそもそもレコード側で記述されていますが、キャッシュ側でレコードの値を書き換えます。
max-cache-sizeで制限すると新旧問わずレコードが消去されてしまいますが、メモリに限界があるときにはTTLで制限するという手法が好まれます。

TTLを制限するには、named.confのoptionステートメントに
「max-cache-ttl(キャッシュのTTLの最大値)」
「max-ncache-ttl(ネガティブキャッシュのTTLの最大値)」
「cleaning-interval(TTLが切れたレコードを完全に削除する)」
を設定します。

options {
(省略)
    max-ncache-ttl      300; ネガティブキャッシュのTTLを5分にする
    max-cache-ttl       600;  レコードのTTLを10分にする
    cleaning-interval       15;  キャッシュのクリーニングを15分間隔で行なう
(省略)
};


デフォルト値は、max-cache-ttl が 604800(1週間)、max-ncache-ttl が10800(3時間)です。
キャッシュしたレコードのTTLが設定した値よりもともと短かった場合はそちらが適用されます。


3 同時に再起問い合わせを受け付けるクライアント数を制限する
同時に多数の再起問い合わせを受け付けると、DNSサーバはそれだけ多くのメモリを消費することになります。同時に再起問い合わせを受け付けるクライアント数を制限するには、named.conf のoption ステートメントに「recursive-clients」を指定します。

options {
(省略)
    recursive-clients   400;
(省略)
};



デフォルト値は1000です。つまりデフォルトでも同時に1000を上回るクライアントからの再起問い合わせは受け付けないようになっています。大規模なDNSサーバでもなければそれほど多くのクライアントから同時に再起問い合わせを受ける事は無いと思われますが、ワーム攻撃によって問い合わせが急増するケースもあります。また、再起問い合わせは意外と多くのメモリを消費します。

例えば、1000のクライアントから同時に再起問い合わせを受け付けた場合、約20Mバイトのメモリを消費すると言われています。



本日はココまで!
今日覚えておいてもらいたい事項は以下のとおり!

・DNSのメモリ消費量を制限する方法は以下の3通りある。
①「max-cache-size」でキャッシュの最大値を指定できる。キャッシュされたデータ量が指定した値に達すると、新旧問わずキャッシュされたTTLを強制的にゼロ(消去)になる。
②「max-cache-ttl」でキャッシュに残すレコードのTTLを短く出来る。
③「recursive-clients」で同時に再起問い合わせを受け付けるクライアント数を制限できる。





BINDの場合、デフォルトで全てのホストから再起問い合わせを受け付けるようになっています。
BINDでは幾つかの形でアクセス制限を行なうことが出来ます。


①allow-recursion で再起問い合わせを制限する
再起問い合わせを許可するホストを制限します。
注意したいのは、allow-recursionで制限されるのは再起問い合わせのみであるということです。
つまり、再起問い合わせ以外の問い合わせ(自分自身が権限を持つゾーンへの問い合わせ&キャッシュとして既に持っている問い合わせ)については制限されません。

allow-recursion はoptionステートメント内でのみ有効です。
zoneステートメントに記述するとBINDが正常に起動しなくなります。

許可するホストの指定には、ホストアドレスおよびネットワークアドレス単位で指定することが可能です。

options { allow-recursion { any; }; // any で指定した場合は全て許可されます。 };



②再起問い合わせを完全に禁止する
再起問い合わせを完全に禁止するとリゾルバとしての役割を無効にすることができます。
再起問い合わせはメモリ消費量を大幅に消費してしまいますので、再起問い合わせをする必要が無いのであれば無効にしてください。

  options {
      recursion no;
  };


③allow-query で 問い合わせを制限する

再起問い合わせを制限するのでは無く、クエリ(問い合わせ)自体を制限します。

      options {
        allow-query { any; };  // any で指定した場合は全て許可されます。
      };

allow-query はoptionステートメントだけでなくzoneステートメントにも記述することが出来ます。

optionステートメントに記述すると、全ての問い合わせに対して設定が有効になります。

zoneステートメントに記述すると、そのゾーンに関する問い合わせはzoneステートメント内の記述が適用されます。

optionステートメントとzoneステートメントの両方に記述した場合は、そのゾーンに関する問い合わせはzoneステートメント内の記述が適用され、zoneステートメント内に記述が無かったzoneについてはoptionステートメントの記述が適用されます。



④接続そのものを拒否する(blackhole)
DNSサーバに対してクラッキングをしかけるホストが判明した場合、そのホストからの接続そのものを拒否するときに利用するのが「blackhole」です。
blackholeはoptionステートメントにのみ指定することが出来、zoneステートメントには記述できません。

options {
        blackhole {
            192.168.10.100; ←ホスト指定
            192.168.10.0/24; ←ネットワーク指定
        };
};

ここで指定されたホストからは、DNSサーバに対する接続そのものが拒否されます。


⑤ゾーン転送を制限する(allow-transfer)
ゾーン転送を許可するホストを許可します。
ゾーン転送を制限無く許可してしまうと、ゾーンの情報を丸ごと公開することになってしまいますのでセキュリティ上好ましくありません。。
ゾーン転送はデフォルトで「全て許可」となっていますので、allow-transfer の設定で明示的に制限しましょう。

options {
        allow-transfer{ スレーブ・サーバ1のIP;  スレーブ・サーバ2のIP; };
};

allow-transfer はoptionステートメントとzoneステートメントの両方に記述することが出来ます。allow-query と同様に両方に記述した場合は、そのゾーンに関してはzoneステートメント内の記述が優先されます。

optionステートメントの設定がデフォルト値(全て許可)となるので、optionステートメントの方をnone; を指定し、zoneステートメント内で各々ゾーンごとにゾーン転送を許可する設定の仕方がオススメです。


options {
allow-transfer { none; };
};



本日はここまで!
今日覚えておいてもらいたい事項は以下のとおり。

・デフォルトで全てのホストから再起問い合わせを受け付けるようになっている。
・allow-recursion で再起問い合わせしてくるホスト(送信元IP)を制限できる。
・再起問い合わせ(リゾルバ)をする必要が無いのであれば無効にしたほうが良い(メモリが大幅軽減)
・allow-query で 問い合わせしてくるホスト(送信元IP)を制限できる。
・blackholeでDNSサーバへの接続そのものを拒否する。
・allow-transferでゾーン転送を制限できる。※デフォルトだと全てのゾーン情報を丸ごと転送してしまう。


つぎにスレーブサーバを構築します。

スレーブサーバはゾーンファイルを作成する必要がありません。なぜならばスレーブサーバのゾーンファイルはマスターサーバに作成したものを転送するからです。

なので、named.confを編集するだけです。

zone "dns-test.com" IN {
type slave; ★①
masters { 1.1.1.1; }; ★②
file "slaves/dns-test.com.slave.zone"; ★③
};

★①・・・Type を Slave と明記。
★②・・・マスターサーバを指定。
★③・・・ゾーンファイル名を指定。

named.confの修正が終わったらBINDを再起動させます。
起動と同時にゾーン転送が行なわれ、ゾーンファイルが自動的に作成されます。ゾーンが転送が正しく行なわれたかどうかは、ゾーンファイルを確認することで行なうことができます。



ゾーン転送が行なわれるタイミングは、SOAレコードの設定によって決定します。

しかし、それではゾーンファイルが書き換わってからゾーン転送が行なわれるまでタイムラグが発生してしまいます。そこでDNS8から「DNS NOTIFY」という手法が実装されました。

DNS NOTIFY を使用することで、ゾーンファイルに変更が加わった場合、直ちにゾーン転送が行なわれます。

①マスタサーバでゾーンファイルが変更され、読み込まれます。
②マスターサーバからスレーブサーバにNOTIFYメッセージを送信します。
③NOTIFYメッセージを受け取ったスレーブサーバはマスタサーバにゾーン転送の要求を出します。
④マスタサーバは要求がスレーブサーバからのものであることを確認し、ゾーン転送を行ないます。

マスターサーバは、NOTIYメッセージをNSレコードに登録されたサーバに対して発信します。
つまり、NOTIFYメッセージを受け取るにはそのサーバがゾーンファイル内のNSレコードに記述されている必要があります。

もし、NSレコードに記述されていないホストにNOTIFYメッセージを送りたい場合は、マスターサーバ側のnamed.confに以下を追記します。

also-notify { 1.1.1.100; };


本日はココまで!

覚えておくべきキーワードは、、、、
・スレーブサーバはゾーンファイルの作成が不要。named.confだけ。
・NOTIFYメッセージを使えば、ゾーンファイルに変更があった際に直ちにゾーン転送が行なわれる。
・NOTIFYメッセージはNSレコードに記述されているサーバに対して送信される。










↑このページのトップヘ