Bug#985616: Document change to unbound ".d" config file fragment behavior
Robert Edmonds wrote:
> During the bullseye release cycle the default /etc/unbound/unbound.conf
> file was changed to use the newly introduced "include-toplevel:"
> directive rather than the "include:" directive. This should probably be
> mentioned in the bullseye release notes because it will break
> configurations where the user added a clauseless config file fragment to
> The text from /usr/share/doc/unbound/NEWS.Debian.gz about this change is
> quoted below.
For the Release Notes we ought to add some material: people reading
the NEWS file can be assumed to have chosen to install unbound, but
this version needs to start by making it clear what unbound is (and
that if you haven't heard of it you don't need to read the technical
details). Then after that we could squeeze things a bit:
<title>Config file fragment handling in unbound</title>
The DNS resolver <systemitem role="package">unbound</systemitem>
has changed the way it includes configuration file fragments.
Instead of using an <literal>include:</literal> directive to read
in files in <filename>/etc/unbound/unbound.conf.d/*.conf</filename>,
the default configuration file for Debian bullseye uses
<literal>include-toplevel:</literal>, which has extra requirements.
Instead of allowing fragments that need to be concatenated to form
valid configuration clauses, <literal>include-toplevel:</literal>
requires each one to begin its own clause (e.g.,
<literal>server:</literal>). If your system uses included fragments
you should ensure they will still be valid; if this is not possible
the previous behavior can be restored by editing
<filename>/etc/unbound/unbound.conf</filename> and switching the
<literal>include-toplevel:</literal> directive back to
Is that compressed too far? I was hoping to fit the word "robustness"
somewhere. Maybe a mention of unbound-checkconf?
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package