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 <[email protected]> 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).).
