每个教程似乎对此都有不同的看法。 对于我的ISC BIND区域，我应该使用/etc/bind/zones/或/var/cache/bind/ ？ 在最后一次安装中，我使用了/var/cache/bind/但仅仅是因为我被引导去做; 但是我刚刚发现了一个用于Debian安装的pid文件，所以我认为使用“工作目录”来存储区域文件可能不是最好的主意。 看来，许多pipe理员使用这个，所以他们不必在声明一个新的区域时input完整的path。
例如：
file "/etc/bind/zones/db.foobar.com";
代替：
file "db.foobar.com";
打字显然比较容易，但这是好还是不好的做法？
有些人也可能build议将工作目录设置为/etc/bind/zones ：
options { // directory "/var/cache/bind"; directory "/etc/bind/zones"; }
…但有些东西告诉我，这不是一个好的做法，因为我会假设（除非它恰好在/var/cache/bind ）创build了pid文件。
我看了看手册，但似乎没有说目录选项是什么，任何想法到底是什么devise？
对于你的主区域，他们应该进入/etc/bind/zones因为他们是configuration。 辅助（从属）区域应位于/var/cache/bind/secondary或类似区域，因为如果数据丢失，它只能从主节点获取高速caching的数据。
一个简短的答案是，这并不重要，或者将工作。
我曾经使用/var/cache/bind ，但是现在我总是使用/etc/bind作为/var/cache通常从备份中排除（每个FHS /var/cache 必须能够自动重新创build）。
任何二级或dynamic区仍然位于/var/cache 。
这不是一个绑定的问题 – 答案取决于你如何pipe理你的Linux / Unix机器。
我曾在需要特定批准的变更pipe理/安全标准的地方工作，在生产服务器上的/ etc树中进行修改，并使用Tripwire或类似工具来监视变更。 在这些地方，具有较高变化速度的文件（即区域文件等）将存在于/ var中，并将受到不同程度的变化评论。
如果你是变更控制过程不是问题，实际的位置并不重要，但你应该保持一致。 就我个人而言，我认为它属于/ var树，但这更多的是我拥有的一个老式的unix习惯。
就像womble一样，我同意/var/cache/bind对辅助（slave）区域有好处。 另一方面，我认为主区不应该在/etc 。 它们是configuration文件，就像Apache提供的内容一样多，所以它们应该存储在/var下的某个地方，而不是存放在/var/cache 。
为了logging，基于Red Hat的系统存储/var/named下的区域（可能自动复制到/var/named/chroot/var/named ）。 configuration文件是/etc/named.conf 。
/ var / lib / bind / – 主区域和dynamic区域
/ var / cache / bind / – 辅助区域
/ etc / bind / – 在服务器的生命周期内不应更改的区域。
我会认为/ var / cache会是你可以删除的东西，所以会使用别的东西。
那就是既不是标准也不是要求。 BIND不关心，只要你一致，你不会盲目编辑configuration文件。
我不会将区域文件视为configuration数据。 named.conf和keys.confconfiguration给我，区域数据就是区域数据。 只要select一个地方 – 也许甚至是一个专门用于这个目的的用户目录 – 并运行它。
在我的具体设置中，我使用/ local / named，这可能是机器上其他地方的符号链接。 我将named.conf放在/ local / named /目录下，并且把目录选项设置为/ local / named。 然后我给像pri / example.com或sec / example.com这样的文件名来保留区域我是权威的，与我从其他来源获得的不同。 这可以让我删除所有的辅助和重新获取，而无需担心，如果我需要。