PR

bind – forward

2010.06.30

#何にしても同じだと思うが、最初から完璧なものなどない。追加や削除を行ない適宜目標を達成していくものだ。それを成長というなら、現在のネットワークは複雑怪奇なものに成長している。そしてそれは思いもよらぬところで足かせとなる。もっとも、それぞれ独立して本来の仕事だけをこなすようにしてやれば幾分それは防げる。ところがそれを可能にするほど潤沢ではない。

◆動作条件

※設定が正しく、かつ最適であるかは不明だが、とりあえず動作している

  • 内部ネットワークの端末はこのサーバーをプライマリDNSサーバーとして指定する。
  • このサーバーは内部からの問い合わせを外部へ問い合わせることと、内部のアドレスを返すことをする。
  • WEBサーバーは別のプライベートアドレスに存在し、ドメインを取得していて、外部からもアクセス可能になっている。
  • 外部からのアクセスはレジストラが用意しているネームサーバーに自分自身のグローバルアドレスを設定している。
  • 外部からポート80へのアクセスはルータのルーティングによって内部のWEBサーバ:80へ転送される。
  • 内部の端末が内部にあるドメインにアクセスしようとしたら、内向きDNSによってプライベートアドレスを返す。

スポンサードリンク

言い方を変えると

  • 外部からはレジストラのネームサーバを使うから放置
  • 外部からの来客はルータによって特定の内部端末にご案内
  • 内部の名前解決は基本丸投げ。ただし、ネットワーク内部に存在するドメインの場合に限りプライベートアドレスのご案内

ちなみに、bindと関係ないけど、この面倒な構成の利点は、問題が発生したときに外部からのアクセスだけを待機系に切り替えて運用することができるということ。

待機系にはWEBサーバだけ立ち上げておき、.htaccessで404を出さないように全てのアクセスをメンテしてます.htmlにmod_rewriteしておく。内部からはメンテナンスとしていつもどおり作業でき、外部からはメンテナンスしてます.htmlだけが見られる。

通常のメンテナンスなら本番系の.htaccessだけ書き換えて、特定の端末以外はメンテしてます.htmlにすればよいが、それでは解決できないような場合には大元で切り替えることができるので便利。DNSを更新するより切り替えが早いし、１箇所だけですべて済む。

◆サンプル

options {
 directory "/etc";
 pid-file "/var/run/named/named.pid";
 forward first;
 forwarders {
  202.***.176.1;
  202.***.176.2;
  };
};
zone "." {
 type hint;
 file "/etc/db.cache";
};
zone "****.jp" {
 type master;
 file "/var/named/****.jp.hosts";
 forwarders {};
};

参考文献

スポンサーリンク

コメント