Home / server / Questions / 85161
Accepted
Nick Bolton
Asked: 2009-11-17 06:07:51 +0800 CST

Should I use /etc/bind/zones/ or /var/cache/bind/?

  • 772

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/db.foobar.com";

Instead of:

file "db.foobar.com";

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?

bind

6 Answers

  1. Best Answer

    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.

    • 17

  2. /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.

    • 5

  3. 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.

    • 2

  4. 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.

    • 2

  5. 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/example.com or sec/example.com 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.

    • 1

  6. 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.

    • 1