Re: BIND 9: substantially updated: https://wiki.debian.org/BIND9
Thanks,
And I'll note in the wiki page source comments.
Be glad to improve it if I well confirm.
But I seemed to find things at least somewhat different than that ...
On Sun, Sep 14, 2025 at 8:25 PM jeremy ardley <jeremy.ardley@gmail.com> wrote:
> Regarding the location of primary zone files, that has previously been
> in /var/cache/bind, and secondary zone files definitely go there.
Debian seems to split that bit differently, at least as far as I can tell.
Some of the contents in /usr/share/doc/bind9 and/or
the maintainer provided apparmor files seem to at least hint at it
(along with of course, Debian Policy and FHS, etc.), but still may not be
100% clear.
As for primary, seems to be, as far as I can tell, one of two locations:
for static, e.g. no use of DDNS and no DNSSEC in-line signing or the
like, etc., basic just classic manually (or otherwise) maintain the zone files,
update those, reload those, nothing else changing them or altering the
final presented data for the zone, those go in (or at least under) /etc/bind/
directory. Some (much?) older content from Debian and/or ISC seems
to have suggested or used /etc/bind/master but use of master (etc.)
is at best quite deprecated, so that shouldn't really be current or
go-forward naming. So, I suggested /etc/bind/primary, or one could
place them directly in /etc/bind/ - as far as I can tell either seems
acceptable and plays well with Debian's presumptions and
expectations, Policy, what documentation Debian provides and
hints at (e.g. apparmor), etc. But that picture changes once
primary goes to dynamic content, e.g. DDNS, or DNSSEC with
in-line signing - essentially anything where bind9 now changes the
zone content - either dynamically, or via other programmatic ways (BIND 9
does also have other means to modify zones, e.g. add, drop, otherwise
alter, etc.)
or, e.g. with DNSSEC in-line signing, then /etc/bind (and /etc/ more
generally) no
longer appropriate, as those are to be (relatively) "static", and not altered by
bind9 (notably bind ID or group) itself. And for those, where that host/server
is primary, and the content dynamic, etc., it seems pretty clear that
/var/lib/bind/ is to be used for that.
However, for secondaries - basically cached data - where that
host/server isn't primary,
that uses yet another location: /var/cache/bind/ - so I think it
distinguishes that as less
critical - e.g. could have entire contents under /var/cache/bind/
blown away, and no big
deal, as that's all just cache data and can generally be reloaded,
unlike /var/lib/bind/ which does
or may include authoritative reference data, e.g. primary zone files
(notably for DDNS
or other primary zones that aren't of purely "static" content).
> Locating primary zone files in /etc/bind/primary does not seem to be usual.
Certainly the addition of primary directory not at all default. I merely
suggested folks might want to do that for, e.g. organizational clarity,
or possible additional security, etc. And somewhat similar(ish) to how
master directory may have been used in past (by Debian and/or ISC),
but master should no longer be used (and will probably only be more
confusing as time marches on if/where it still remains). In any case,
the directory primary I suggested under /etc/bind/ would again, only be
for "static" content, not dynamic zones (including primary), etc. notably
as bind (user and group) shouldn't have write access at/under /etc/bind/
(and most notably due to at least default apparmor configuration).
> There is an alternative location for primary zone files in /var/lib/bind
> but it does not seem common either.
Actually, as far as I can tell, that's what's most commonly intended
for primary zones in the case of dynamic (DDNS, etc.) content.
And, wish I could say the evidence/pointers/documentation/etc.
from Debian was much more clear on this ... it's not super clear.
But in addition to Debian Policy (and FHS, etc.) we do seem to have
at least some hints, e.g.:
>From Debian 7:
$ ar p bind9_9.8.4.dfsg.P1-6+nmu2+deb7u10_amd64.deb data.tar.gz | gzip
-d | tar -O -xf - ./etc/apparmor.d/usr.sbin.named | sed -ne '/bind
should be/,/README/p'
# /etc/bind should be read-only for bind
# /var/lib/bind is for dynamically updated zone (and journal) files.
# /var/cache/bind is for slave/stub data, since we're not the origin of it.
# See /usr/share/doc/bind9/README.Debian.gz
$
from sid:
$ ar p bind9_9.20.11-4+b1_amd64.deb data.tar.xz | xz -d | tar -O -xf -
./etc/apparmor.d/usr.sbin.named | sed -ne '/bind should be/,/README/p'
# /etc/bind should be read-only for bind
# /var/lib/bind is for dynamically updated zone (and journal) files.
# /var/cache/bind is for slave/stub data, since we're not the origin of it.
# See /usr/share/doc/bind9/README.Debian.gz
$
>From experimental:
$ ar p bind9_9.21.10-10+b1_amd64.deb data.tar.xz | xz -d | tar -O -xf
- ./etc/apparmor.d/usr.sbin.named | sed -ne '/bind should
be/,/README/p'
# /etc/bind should be read-only for bind
# /var/lib/bind is for dynamically updated zone (and journal) files.
# /var/cache/bind is for slave/stub data, since we're not the origin of it.
# See /usr/share/doc/bind9/README.Debian.gz
$
Debian does also default the directory setting in bind9
to /var/cache/bind/ - but that inherently needs be writable
by bind, so that may not be (most) suitable for all such content.
Would also seem logical to have the more and less important
content of /var/lib/bind/ and /var/cache/bind/ be separate,
e.g. one may want to well and regularly backup the contents of
/var/lib/bind/ but perhaps not bother backing up contents of /var/cache/bind/
We do also have these relevant bits from /usr/share/doc/bind9/README.Debian
(this one from sid 1:9.20.11-4+b1): (and not quoted in entirety - I
left some bits out
for brevity/clarity):
"
The named configuration file named.conf is located in /etc/bind, so that all
static configuration files relating to bind are in one place.
The working directory for named is now /var/cache/bind. Thus, any transient
files generated by named, such as database files for zones the daemon is
secondary for, will be written to the /var filesystem, where they belong.
To make this work, the named.conf provided uses explicitly fully-qualified
pathnames to reference the files in /etc/bind.
While you are free to craft whatever structure you wish for servers which need
to be authoritative for additional zones, what we suggest is that you put the
db files for any zones you are primary for in /etc/bind (perhaps even in a
subdirectory structure depending on complexity), using full pathnames in the
named.conf file. Any zones you are secondary for should be configured in
named.conf with simple filenames (relative to /var/cache/bind), so the data
files will be stored in BIND's working directory (defaults to /var/cache/bind).
Zones subject to automatic updates (such as via DHCP and/or nsupdate) should be
stored in /var/lib/bind, and specified with full pathnames.
"
Even the corresponding README.Debian.gz in Debian 7 says mostly
fairly similar - at least to the extent it covers such.
So, I still don't think that makes it absolutely 100% clear, but
between that and
the hintss in apparmor, seems to suggest secondaries and other cached data
in /var/cache/bind/, primaries: "static" in/under /etc/bind/ and
dynamic primaries
and the like in /var/lib/bind/ - I may not be 100% correct, but that's
what I seem
to make of it (and does also play nice with the apparmor configuration - beyond
what it merely has in the comments in that file - most notably dynamic
is a no-go
for in/under /etc/bind, unless one substantially modifies apparmor
configuration,
and that could be inappropriately risky, as, e.g. it might allow bind
to modify its
own key configuration files under /etc/bind/ so probably not a good idea,
at least for that directory itself.).
In all cases, thanks for the input! And yeah, some of this isn't all 100%
clear, and may have also shifted over the years/versions too.
And on the wiki page, I mostly aligned to what seems to be
current for stable - and that mostly seems similar(ish) up
through (approximately) current sid/experimental,
and back through Debian 7 - but I've not generally checked/documented
back earlier than Debian 7 (and probably rather to quite few would be
all that interested in or needing that level of detail for Debian <=6,
also the further away from stable, the more differences and work to
maintain and content(/clutter)
that would be added on the wiki page ... so I figure back through
Debian 7 is probably quite sufficient for
most all purposes (and the differences modest enough, wasn't too hard
to also include back through 7
for most things - notably excepting DNSSEC - only went back through 8
for that).).
Reply to: