web-dev-qa-db-ja.com

/ 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にある場合を除きます）。

manpage を確認しましたが、ディレクトリオプションの用途や、設計の目的について正確に説明していません。

bindnamed-conf
10
Nick Bolton

マスターゾーンの場合、/etc/bind/zonesそれらは設定です。セカンダリ（スレーブ）ゾーンは/var/cache/bind/secondaryまたは同様です。データが失われた場合にマスターから取得できるのは、キャッシュされたデータだからです。

13
womble

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

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

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

2
Mike

簡単に言えば、それは問題ではなく、どちらでも機能するということです。

/var/cache/bind、しかし今は常に/etc/bind なので /var/cacheは通常、バックアップから除外されます（ [〜＃〜] fhs [〜＃〜]ごとに/var/cacheは自動的に再作成できる必要があります）。

セカンダリゾーンまたはダイナミックゾーンは、/var/cache。

2
LapTop006

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

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

2
Cristian Ciupitu

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

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

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

1
duffbeer703

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

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

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

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

0
Michael Graff