/ etc / bind / zones /または/ var / cache / bind /を使用する必要がありますか？

各チュートリアルは、これについて異なる意見を持っているようです。ISC BINDゾーンでは、/etc/bind/zones/またはを使用する必要がありますか/var/cache/bind/？前回のインストールで使用しました/var/cache/bind/が、使用するように指示されたためです。ただし、この新しいDebianインストール用のpidファイルを見つけただけなので、「作業ディレクトリ」を使用してゾーンファイルを保存することは、おそらく最善のアイデアではないと考えました。多くの管理者がこれを使用しているため、新しいゾーンを宣言するときに完全なパスを入力する必要はありません。

例えば：

file "/etc/bind/zones/db.foobar.com";

の代わりに：

file "db.foobar.com";

明らかにタイプする方が簡単ですが、それは良い練習ですか、悪い練習ですか？

作業ディレクトリを/etc/bind/zones次のように設定するよう提案する人もいます。

options {
    // directory "/var/cache/bind";
    directory "/etc/bind/zones";
}

...しかし、pidファイルがそこに作成されるので、これは良い習慣ではないと私に思います（/var/cache/bind偶然ではない限り）。

マンページを確認しましたが、ディレクトリオプションの目的や、それが設計された正確なアイデアは表示されていませんでしたか？

マスターゾーンの場合、それらは構成されている/etc/bind/zonesため、それらを入力する必要があります。セカンダリ（スレーブ）ゾーンは/var/cache/bind/secondary、データが失われた場合にマスターから取得できるキャッシュされたデータであるため、その中にあるか類似している必要があります。

wombleと同じように/var/cache/bind、セカンダリ（スレーブ）ゾーンに適しているという事実に同意します。一方、マスターゾーンはにあるべきではないと思います/etc。これらは、Apacheによって提供されるコンテンツと同じように構成ファイルであるため、の下で/varはなく、の下のどこかに保存する必要があり/var/cacheます。

参考までに、Red Hatベースのシステムは、ゾーンを/var/named（自動的ににコピーされる可能性がある場所から）に保存します/var/named/chroot/var/named。構成ファイルは/etc/named.confです。

/ var / lib / bind /-マスターゾーンとダイナミックゾーン

/ var / cache / bind /-セカンダリゾーン

/ etc / bind /-サーバーの存続期間中変更してはならないゾーン。

簡単に言えば、それは問題ではなく、どちらでも機能します。

以前はを使用/var/cache/bindしていましたが、現在は常にバックアップから除外されているため、常に使用し/etc/bindています/var/cache（FHS ごとに自動的に再作成できる/var/cache 必要があります）。

セカンダリゾーンまたはダイナミックゾーンは引き続きにあり/var/cacheます。

これはバインド問題ではありません。答えは、Linux / Unixボックスの管理方法によって異なります。

私は、運用サーバーの/ etcツリーに変更を加えるために特定の承認を必要とし、Tripwireまたは同様のツールを使用して変更を監視する変更管理/セキュリティ標準のある場所で働いてきました。これらの場所では、変更のテンポが高いファイル（ゾーンファイルなど）が/ varに存在し、異なるレベルの変更レビューの対象となります。

変更管理プロセスが問題ではない場合、実際の場所はそれほど重要ではありませんが、一貫性を保つ必要があります。個人的には、/ varツリーに属していると思いますが、それは私が持っている昔ながらのUNIXの習慣に似ています。

/ var / cacheはあなたが削除できるものだと思うので、他のものを使用します。

つまり、それは標準でもそうである必要もありません。BINDは関係ありません。一貫している限り、構成ファイルをブラインド編集することはありません。

ゾーンファイルを構成データと正確に見なしません。named.confとkeys.confは私にとっては設定ですが、ゾーンデータはゾーンデータです。場所を選択するだけで、おそらくその目的のために専用のユーザーディレクトリを作成して、それで実行できます。

私の特定のセットアップでは、/ local / namedを使用していますが、これはマシンの他の場所のシンボリックリンクである可能性があります。named.confを/ local / named /に配置し、ディレクトリオプションを/ local / namedにも設定します。次に、pri / example.comやsec / example.comなどのファイル名を指定して、他のソースから取得したゾーンと区別できるように、信頼できるゾーンを維持します。これにより、すべてのセカンダリを削除して、心配することなく再フェッチできます。