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レコードに記述されているサーバに対して送信される。










ゾーンファイルにレコードを追加したり、修正した場合は、以下の2点を実施する必要があります。

①SOAレコードのシリアルナンバーも書き換える。

シリアルナンバーを書き換えます。シリアルナンバーは、
「年/月/日/番号」で記載されます。
たとえば、変更を加えた日付が「2014年9月3日」であれば、「2014090301」のように書き換えます。


②ゾーンファイルの再読み込み
BINDにゾーンファイルを読み込ませる必要があります。ゾーンファイルを読み込ませるには、rndcコマンドを利用します。

/usr/sbin/rndc reload



本日は短いですがココまで。

ゾーンファイルを修正する場合は、

・SOAレコードのシリアル番号を書き換える
・ゾーンファイルの再読み込みを行なう

の2点を実行して下さい。

↑このページのトップヘ