![[book image]](data/20040930/4-8399-0930-X.jpg) |
[→
書籍情報] [→ amazon.co.jp] [→ cbook24.com] [→ 関連する日記のエントリ (09/24)] |
LAST MODIFIED: 2008/08/30 18:08:34 UTC
不定期更新の日記です。ディスクスペースの関係上、 あまりに古くなったものは順次消していきます。 この日記の更新は、今野さんの *BSD Diary Links から取得することが可能です。
|
[→
書籍情報] [→ amazon.co.jp] [→ cbook24.com] [→ 関連する日記のエントリ (09/24)] |
最近、研究室や allbsd.org のサーバを入れ換えたり、 ソフトウェアのバージョンをあげたりして整頓していました。 管理しているネームサーバは内部ネットワークと外部ネットワークで 解決できるドメイン名に違いがあります。 BIND を使っているので、
という設定をする必要があります。 この設定、BIND の資料には良く登場するのですが、 複数の view で同じゾーンを見せる時の設定を詳しく書いているものは、 見かけたことがありません。 整頓前も「どう設定するのがスマートなんだろう」と悩んで、 結局、動けばいいや、という風にあまり考えずにいましたが、 これを機に、ちょっと情報を整理してみました。
一番単純に考えれば、
とすれば実現できます。設定ファイルに 2 回も同じ記述をするのは嫌、 というのであれば、include を使って共通部分を別ファイルに分離すれば良いでしょう。
ただ、この方法は、そのゾーンがスレーブだった場合、ちょっと問題になります。 スレーブの場合は、
という設定が、最も単純に思いつくものだと思います。 どちらの view を slave にしても可能です。
b) の設定は、view の構成によっては transfer-source を設定するなりして、 マスターとのアクセスをきちんと制御する必要がありますが、ちゃんと動作します。 しかし、この設定は 1 点だけまずいところがあります。 type master で設定した file は、named の起動前に存在している必要がありますが、 ゾーン転送が終らないと存在しません。なので、初回だけ named を起動する時に file がないよ、 というエラーが出て、type master に指定したゾーンが SERVFAIL になります。 ゾーン転送が終っても、named を再起動しないと type master なゾーンを認識してくれません。
以前は、この b) の設定にして、エラーが出るのは初回だけ注意して、 ごまかしごまかし運用していました。
その後、それを避ける方法をいろいろと考えたところ、 次の設定を思いつきました。
c) は、両方とも別個の slave にしてしまうという方法です。 現実的には可能なのですが、同じデータを 2 回ゾーン転送してしまう、 同じゾーンデータが複数のファイルに保存される、 という点が、無駄な部分になります。
d) は、view 間でゾーン転送してしまおう、というアイディアです。external がマスターサーバのスレーブになり、internal がそれのさらにスレーブになります。 internal が external からゾーン転送するには、view の選択をうまく制御しなければなりませんが、 servers 文と TSIG を使うことで実現できます (transfer-source などの、 IP アドレス指定だけでは、後述の notify 配送の制御が困難です)。
view 間ゾーン転送は、同じゾーンデータが違うファイルに保存されるところに c) と同じ無駄がありますが、両方とも slave なので、b) の起動時問題はありません。 ただ、設定が複雑で直観的ではなく、ゾーン数が増えると理解が困難だと思います。
最も混乱するのは、notify の配送です。BIND のデフォルトでは、 type slave なゾーンも、データのロード時に NOTIFY メッセージを生成します。 スレーブが 2 段階になっていて、かつ view が分かれているので、 その notify がどの view に行くのかを正しく制御する必要があります。 notify が適切なタイミングで適切な場所に配送されないと、ゾーン転送の効率が低下します。 この効率低下は、小さいゾーンでは微々たるものですが、 notify の配送を制御する記述が非常に面倒なので、それが負担になると思います。
e) は、現在使っている設定です。両方の view でゾーンデータを持つのではなく、 query の段階で forward します。IP アドレスベースで view を切替えているのであれば、それぞれの view に対応したアドレスを forwarders に書けば、適切な view への query として扱われますので、 設定は比較的楽です。ゾーンデータは type slave なので、 b) の 起動時問題はありませんし、ゾーンデータを 2 重に持つこともありません。
いろいろと試した後、e) のアイディアにたどり着いて使っているのですが、 この方法、本当に適切なのか、いまひとつ自信がありません。 調べた限りでは、基本的な挙動に問題はないように見えます。 forward しているゾーンは authoritative answer を返しませんが、 片方の view で AA がないという状況が、 何か重大な不都合となることはないと思います。
しかし、これも 1 点だけうまく動かないところがあります。 type master なゾーンに対して type forward を設定して、 かつ、その master ゾーンに dynamic update を設定すると、 forward ゾーンで SERVFAIL が出ます。dynamic update しない場合や、 slave に設定している時には問題なく動作するのですが、 なぜか dynamic update するとダメなようです。
どうしてダメなのか理解できないでいるのですが、 SERVFAIL になるのは type master の時だけなので、 とりあえずマスターサーバでは a) の設定 (両方を type master にして file 設定は同一) を使い、 片方のみ allow-update を設定して回避しています。
‥‥と、試行錯誤し始めて、かれこれ 1 年くらい経つような気がします。 自分の中で結論が出ていないもののひとつです。
プライベートアドレスで構成された 2 つの分離されたネットワーク間を接続するために、 両方のネットワーク端にグローバルアドレスの付いたルータマシンを用意して、 gif(4) の IPv4-IPv4 トンネルを使って接続。 ルーティングは RIP にしようと思って久しぶりに routed の設定をしたところ、いくつかはまったりしたので、 忘れないようにまとめてメモ。
FreeBSD の routed は、unnumbered では使えない。 gif(4) の両端には IPv4 アドレスを付ける必要がある。
RIP を流したくない if には、/etc/gateways に if=fxp0,passive のように設定する。
RIP を流すが、経路情報を受け取りたくない場合は、 /etc/gateways に if=fxp0,ripv2,no_ripv2_in,no_solicit,no_rdisc,no_rdisc_adv のように設定する。デフォルトルートを広告したい場合は fake_default (RIPv1 しか受け取れないクライアントがあるなら pm_rdisc) が便利。
IPv4 アドレスを複数付けている NIC がある場合、 routed が混乱するので注意。routed は、1 つの NIC に対して 1 つのサブネットが存在することを前提に設計されている。 そのため、複数のサブネットに属する IP アドレスが割り当てられていると、 そのサブネットの直接経路の一部が消えてしまう症状が発生する。 RIP を無効にする以外、回避できない。
gif(4) に付ける IPv4 アドレスは point-to-point なので destination も設定しなければならないのだけど、 netmask はどう設定するのが正しいのかしら? src と dest の 2 つのアドレスがひとつのサブネットに属していると考えるのが正しい?
LAST MODIFIED: 2008/08/30 18:08:34 UTC