Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Each tutorial seems to have a different opinion on this. For my ISC BIND zones, should I use /etc/bind/zones/ or /var/cache/bind/? In the last install, I used /var/cache/bind/ but only because I was guided to do so; however I just spotted a pid file in there for this new Debian install, so I figured that using the "working directory" to store zone files probably wasn't the best idea. It seems that many admins use this so they don't have to type the full path when declaring a new zone.

For example:

file "/etc/bind/zones/";

Instead of:

file "";

Is obviously easier to type, but is it good or bad practice?

Some may also suggest setting the working directory to /etc/bind/zones:

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

... but something tells me this isn't good practice, since the pid file would be created there I assume (unless it's just in /var/cache/bind by coincidence).

I took a look at the manpage but it didn't seem to say what the directory option was for, any ideas exactly what it was design for?

share|improve this question
up vote 12 down vote accepted

For your master zones, they should go in /etc/bind/zones because they're config. Secondary (slave) zones should be in /var/cache/bind/secondary or similar, because it's just cached data that can be retrieved from the master if the data is lost.

share|improve this answer

A short answer is that it doesn't matter and either will work.

I used to use /var/cache/bind, but now I always use /etc/bind as /var/cache is usually excluded from backups (per the FHS /var/cache must be able to be recreated automatically).

Any secondary or dynamic zones still live in /var/cache.

share|improve this answer

This isn't really a Bind question -- the answer depends on how you manage your Linux/Unix boxes.

I've worked in places with change management/security standards that require specific approval to make modifications in the /etc tree on a production server, and use Tripwire or similar tools to monitor for changes. In those places, files with a high tempo of change (ie Zone files, etc) would live in /var and would be subject to a different level of change review.

If you're change control process isn't an issue, the actual location doesn't matter much, but you should keep it consistent. Personally, I think it belongs in the /var tree, but that's more of an old school unix habit that I have.

share|improve this answer

Just like womble, I agree with the fact that /var/cache/bind is good for secondary (slave) zones. On the other hand, I don't think that master zones should be under /etc. They are configuration files just as much as content served by Apache is, so they should be stored somewhere under /var, but not under /var/cache.

Just for the record, Red Hat based systems store zones under /var/named (from where they might be copied automatically to /var/named/chroot/var/named). The configuration file is /etc/named.conf.

share|improve this answer

/var/lib/bind/ - master and dynamic zones

/var/cache/bind/ - secondary zones

/etc/bind/ - zones that should not change for the lifetime of the server.

share|improve this answer
I also prefer this pattern, but is this an official recommendation somewhere? – Jon Skarpeteig Apr 25 at 9:48

I would think /var/cache would be something you could delete, and so would use something else.

What that is, is neither a standard nor a requirement to be so. BIND doesn't care, just so long as you're consistent about it you won't go blind editing config files.

I would not consider zone files as configuration data exactly. named.conf and keys.conf are config to me, zone data is, well, zone data. Just pick a place -- perhaps even a user directory dedicated for the purpose -- and run with it.

In my specific setup, I use /local/named, which may be a symlink elsewhere on the machine. I put named.conf in /local/named/, and set the directory option to /local/named as well. I then give filenames like pri/ or sec/ to keep zones I am authoritative for distinct from those I pull from other sources. This lets me remove all secondaries and re-fetch without worry should I need to.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.