Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-20 01:03:36 +0300, Michael Tokarev wrote:
> 20.04.2022 00:58, Vincent Lefevre wrote:
> > On 2022-04-20 00:43:48 +0300, Michael Tokarev wrote:
> > > 20.04.2022 00:40, Vincent Lefevre wrote:
> > > 
> > > > > Well, systemd already have its own nameserver configuration and its
> > > > > own resolver cache which does not need any reload of daemons, since
> > > > > resolv.conf does not change (It does not change with resolvconf and
> > > > > unbound running with resolvconf hook enabled, either, and postfix
> > > > > already needs no restart).
> > > > 
> > > > But AFAIK, it doesn't have a way to fall back to the nameservers
> > > > provided by DHCP.
> > > 
> > > Yes. Neither does unbound or other nameservers shipped in Debian,
> > > because there's just no _notion_ of "fall back".
> > 
> > Wrong. The normal use of /etc/resolv.conf via glibc does
> > (so, assuming that resolvconf is not installed).
> > See additional information in my mail to bug 1003135.
> 
> glibc is not a nameserver, Vincent.  Please actually read what I write
> before saying I'm wrong.

glibc is not a nameserver, but it provides functions to resolve
hostnames. This is what applications see.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Michael Tokarev]

20.04.2022 00:58, Vincent Lefevre wrote:

On 2022-04-20 00:43:48 +0300, Michael Tokarev wrote:

20.04.2022 00:40, Vincent Lefevre wrote:


Well, systemd already have its own nameserver configuration and its
own resolver cache which does not need any reload of daemons, since
resolv.conf does not change (It does not change with resolvconf and
unbound running with resolvconf hook enabled, either, and postfix
already needs no restart).


But AFAIK, it doesn't have a way to fall back to the nameservers
provided by DHCP.


Yes. Neither does unbound or other nameservers shipped in Debian,
because there's just no _notion_ of "fall back".


Wrong. The normal use of /etc/resolv.conf via glibc does
(so, assuming that resolvconf is not installed).
See additional information in my mail to bug 1003135.


glibc is not a nameserver, Vincent.  Please actually read what I write
before saying I'm wrong.

/mjt

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-20 00:43:48 +0300, Michael Tokarev wrote:
> 20.04.2022 00:40, Vincent Lefevre wrote:
> 
> > > Well, systemd already have its own nameserver configuration and its
> > > own resolver cache which does not need any reload of daemons, since
> > > resolv.conf does not change (It does not change with resolvconf and
> > > unbound running with resolvconf hook enabled, either, and postfix
> > > already needs no restart).
> > 
> > But AFAIK, it doesn't have a way to fall back to the nameservers
> > provided by DHCP.
> 
> Yes. Neither does unbound or other nameservers shipped in Debian,
> because there's just no _notion_ of "fall back".

Wrong. The normal use of /etc/resolv.conf via glibc does
(so, assuming that resolvconf is not installed).
See additional information in my mail to bug 1003135.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-19 19:11:42 +0300, Michael Tokarev wrote:
> 19.04.2022 17:49, Vincent Lefevre wrote:
> ..
> > > I don't think this is in the scope of resolvconf people, because
> > > the whole purpose of resolvconf is different.
> > 
> > I don't know what you mean here. In my case, the purpose of resolvconf
> > is just to restart postfix each time /etc/resolv.conf is modified
> 
> resolvconf does not "check" updates of resolv.conf, it *manages*
> resolv.conf and maintains a list of available nameservers, including
> nameservers provided by DHCP.

My point is that the postfix package provides a resolvconf hook to
restart postfix when /etc/resolv.conf changes:
/etc/resolvconf/update-libc.d/postfix

This is why resolvconf is the recommended way to make sure that
postfix uses up-to-date nameservers.

> Well, systemd already have its own nameserver configuration and its
> own resolver cache which does not need any reload of daemons, since
> resolv.conf does not change (It does not change with resolvconf and
> unbound running with resolvconf hook enabled, either, and postfix
> already needs no restart).

But AFAIK, it doesn't have a way to fall back to the nameservers
provided by DHCP.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Michael Tokarev]

20.04.2022 00:40, Vincent Lefevre wrote:


Well, systemd already have its own nameserver configuration and its
own resolver cache which does not need any reload of daemons, since
resolv.conf does not change (It does not change with resolvconf and
unbound running with resolvconf hook enabled, either, and postfix
already needs no restart).


But AFAIK, it doesn't have a way to fall back to the nameservers
provided by DHCP.


Yes. Neither does unbound or other nameservers shipped in Debian,
because there's just no _notion_ of "fall back".

Thanks,

/mjt

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Michael Tokarev]

19.04.2022 17:49, Vincent Lefevre wrote:
..

I don't think this is in the scope of resolvconf people, because
the whole purpose of resolvconf is different.


I don't know what you mean here. In my case, the purpose of resolvconf
is just to restart postfix each time /etc/resolv.conf is modified


resolvconf does not "check" updates of resolv.conf, it *manages*
resolv.conf and maintains a list of available nameservers, including
nameservers provided by DHCP.

[]

I tend to close this bug report, Vincent.  This is not the intended
usage of resolvconf, and is not something to fix in unbound, either.
Unbound can either accept whatever resolvconf gives it from dhcp and
use that as its own forwarders (with the the script in $subject
enabled), or it can continue to perform recursive queries as before,
starting with the root nameservers.  There's no such thing as a
"fallback" here, at all.


Then this should be a resolvconf bug. But the fix on the postfix side


There's no bug per se, at least I still can't see one.
And there's no "fallback" here. either.


(Debian bug 1003152) makes resolvconf no longer needed. So, as long
as other Debian packages do not need resolvconf, I no longer care
about it.


Well, systemd already have its own nameserver configuration and its
own resolver cache which does not need any reload of daemons, since
resolv.conf does not change (It does not change with resolvconf and
unbound running with resolvconf hook enabled, either, and postfix
already needs no restart).

Thank you for your patience!

/mjt

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-19 16:24:57 +0300, Michael Tokarev wrote:
> 19.04.2022 16:02, Vincent Lefevre wrote:
> > On 2022-04-19 15:15:11 +0300, Michael Tokarev wrote:
> > > unbound resolvconf integration (the disabled one) works by setting
> > > DNS servers obtained via DHCP to become the forwarders in
> > > unbound.  As simple as that.  I'm not saying about 127.0.0.1
> > > filtering there, it's a different issue.
> > > 
> > > If we (re)enable /etc/resolvconf/update.d/unbound , the dhcp-provided
> > > nameservers will be used as the primary nameservers with unbound sitting
> > > just as a local cache. Unbound will not use them as fallbacks but as
> > > primary forwarders.
> > 
> > The issue is that resolvconf assumes that unbound will use them
> > as fallbacks (see below).
> 
> Um. Did you forget to describe this "below" case? I don't see where you
> wrote that below.

No, I meant what I wrote about how resolvconf behaves.

> > > The only way to do what - I think - you're asking for, is for
> > > resolvconf to modify /etc/resolv.conf file to specify one unbound-
> > > provided nameserver line (with 127.0.0.1 in there) and *add* the
> > > dhcp-provided nameservers there *too*. And you don't want in this
> > > case to enable unbound's resolvconf integration.
> > 
> > resolvconf actually does the opposite: instead of leaving the
> > /etc/resolv.conf contents as is, it removes every nameserver
> > after 127.0.0.1, assuming that they will be handled by the
> > local nameserver.
> 
> Yes, I know what it does, and why.  It assumes whatever is running
> at 127.* is a local caching thing which will do its own forwarding
> when needed, and for that forwarding resolvconf gives it the
> dhcp-provided nameservers.  What I wrote is the only way I know
> to achieve what you wanted.
> 
> > Perhaps this is something to see with the resolvconf authors.
> 
> I don't think this is in the scope of resolvconf people, because
> the whole purpose of resolvconf is different.

I don't know what you mean here. In my case, the purpose of resolvconf
is just to restart postfix each time /etc/resolv.conf is modified
(typically due to the connection of a laptop to a different network),
as recommended at

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964762

However, the upcoming postfix package version will contain another
method without needing resolvconf:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003152

> > > But this doesn't really work and it is unreliable.  Because quite
> > > some software will query *all* nameservers listed in resolv.conf
> > > at the same time (accepting the first reply), and some software
> > > will only query the first one.
> > 
> > This would clearly be a bug, as not conforming with the
> > /etc/resolv.conf spec. See the resolv.conf(5) man page:
> 
> I know perfectly well what resolv.conf manage says.  And I know
> perfectly well that software already uses it in slightly different
> ways, for different reasons. Usually you don't have lots of stuff
> in there - it is either your upstream nameservers from dhcp, or
> something like 8.8.8.8, or 127.0.0.{1,53} which is your local
> dns cache.  In most cases it is irrelevant in which way or in
> which order you query them.

There is another use case: by default, have some nameserver
that doesn't use the ones provided by DHCP, e.g. 127.0.0.1
or 8.8.8.8, and have the nameservers provided by DHCP as a
fallback. The fallback is needed in case UDP packets are
filtered, as with captive portals; see example at

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003135

and it is important that the query to the default nameserver
is done first, because the nameservers provided by DHCP can
provide incorrect answers (e.g. preventing users from using
servers blacklisted by the government).

> I tend to close this bug report, Vincent.  This is not the intended
> usage of resolvconf, and is not something to fix in unbound, either.
> Unbound can either accept whatever resolvconf gives it from dhcp and
> use that as its own forwarders (with the the script in $subject
> enabled), or it can continue to perform recursive queries as before,
> starting with the root nameservers.  There's no such thing as a
> "fallback" here, at all.

Then this should be a resolvconf bug. But the fix on the postfix side
(Debian bug 1003152) makes resolvconf no longer needed. So, as long
as other Debian packages do not need resolvconf, I no longer care
about it.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Michael Tokarev]

19.04.2022 16:02, Vincent Lefevre wrote:

On 2022-04-19 15:15:11 +0300, Michael Tokarev wrote:

unbound resolvconf integration (the disabled one) works by setting
DNS servers obtained via DHCP to become the forwarders in
unbound.  As simple as that.  I'm not saying about 127.0.0.1
filtering there, it's a different issue.

If we (re)enable /etc/resolvconf/update.d/unbound , the dhcp-provided
nameservers will be used as the primary nameservers with unbound sitting
just as a local cache. Unbound will not use them as fallbacks but as
primary forwarders.


The issue is that resolvconf assumes that unbound will use them
as fallbacks (see below).


Um. Did you forget to describe this "below" case? I don't see where you
wrote that below.


The only way to do what - I think - you're asking for, is for
resolvconf to modify /etc/resolv.conf file to specify one unbound-
provided nameserver line (with 127.0.0.1 in there) and *add* the
dhcp-provided nameservers there *too*. And you don't want in this
case to enable unbound's resolvconf integration.


resolvconf actually does the opposite: instead of leaving the
/etc/resolv.conf contents as is, it removes every nameserver
after 127.0.0.1, assuming that they will be handled by the
local nameserver.


Yes, I know what it does, and why.  It assumes whatever is running
at 127.* is a local caching thing which will do its own forwarding
when needed, and for that forwarding resolvconf gives it the
dhcp-provided nameservers.  What I wrote is the only way I know
to achieve what you wanted.


Perhaps this is something to see with the resolvconf authors.


I don't think this is in the scope of resolvconf people, because
the whole purpose of resolvconf is different.


But this doesn't really work and it is unreliable.  Because quite
some software will query *all* nameservers listed in resolv.conf
at the same time (accepting the first reply), and some software
will only query the first one.


This would clearly be a bug, as not conforming with the
/etc/resolv.conf spec. See the resolv.conf(5) man page:


I know perfectly well what resolv.conf manage says.  And I know
perfectly well that software already uses it in slightly different
ways, for different reasons. Usually you don't have lots of stuff
in there - it is either your upstream nameservers from dhcp, or
something like 8.8.8.8, or 127.0.0.{1,53} which is your local
dns cache.  In most cases it is irrelevant in which way or in
which order you query them.

I tend to close this bug report, Vincent.  This is not the intended
usage of resolvconf, and is not something to fix in unbound, either.
Unbound can either accept whatever resolvconf gives it from dhcp and
use that as its own forwarders (with the the script in $subject
enabled), or it can continue to perform recursive queries as before,
starting with the root nameservers.  There's no such thing as a
"fallback" here, at all.

Thanks,

/mjt

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-19 15:15:11 +0300, Michael Tokarev wrote:
> unbound resolvconf integration (the disabled one) works by setting
> DNS servers obtained via DHCP to become the forwarders in
> unbound.  As simple as that.  I'm not saying about 127.0.0.1
> filtering there, it's a different issue.
> 
> If we (re)enable /etc/resolvconf/update.d/unbound , the dhcp-provided
> nameservers will be used as the primary nameservers with unbound sitting
> just as a local cache. Unbound will not use them as fallbacks but as
> primary forwarders.

The issue is that resolvconf assumes that unbound will use them
as fallbacks (see below).

> The only way to do what - I think - you're asking for, is for
> resolvconf to modify /etc/resolv.conf file to specify one unbound-
> provided nameserver line (with 127.0.0.1 in there) and *add* the
> dhcp-provided nameservers there *too*. And you don't want in this
> case to enable unbound's resolvconf integration.

resolvconf actually does the opposite: instead of leaving the
/etc/resolv.conf contents as is, it removes every nameserver
after 127.0.0.1, assuming that they will be handled by the
local nameserver.

Perhaps this is something to see with the resolvconf authors.

> But this doesn't really work and it is unreliable.  Because quite
> some software will query *all* nameservers listed in resolv.conf
> at the same time (accepting the first reply), and some software
> will only query the first one.

This would clearly be a bug, as not conforming with the
/etc/resolv.conf spec. See the resolv.conf(5) man page:

  nameserver Name server IP address
Internet address of a name server that the resolver should query,
either an IPv4 address (in dot notation), or an IPv6 address in
colon (and possibly dot) notation as per RFC 2373. Up to MAXNS
(currently 3, see ) name servers may be listed, one per
keyword. If there are multiple servers, the resolver library
 ^^^
queries them in the order listed. If no nameserver entries are
^
present, the default is to use the name server on the local
machine. (The algorithm used is to try a name server, and if the
query times out, try the next, until out of name servers, then
repeat trying all the name servers until a maximum number of
retries are made.)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Michael Tokarev]

19.04.2022 14:11, Vincent Lefevre wrote:

On 2022-04-19 13:22:53 +0300, Michael Tokarev wrote:

In my understanding over the years, I expected the nameservers
received from/by DHCP should be used *first*. I did this with
unbound or dnsmasq even before resolvconf has been written -
using custom dhcp script to reconfigure local DNS resolver.

I don't even know unbund has a way to specify "fallback"
nameservers. You either set forwarders for a zone or you don't,
there's no _notion_ of fallback per se.


The fallback is what resolvconf expects and precisely why
bug 1003135 was reassigned from resolvconf to unbound:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003135#40

   "In fact, unbound comes with resolvconf integration, so it should
   know about other nameservers coming from DHCP. [...]"


I still don't understand you here.

unbound resolvconf integration (the disabled one) works by setting
DNS servers obtained via DHCP to become the forwarders in
unbound.  As simple as that.  I'm not saying about 127.0.0.1
filtering there, it's a different issue.

If we (re)enable /etc/resolvconf/update.d/unbound , the dhcp-provided
nameservers will be used as the primary nameservers with unbound sitting
just as a local cache. Unbound will not use them as fallbacks but as
primary forwarders.

The only way to do what - I think - you're asking for, is for
resolvconf to modify /etc/resolv.conf file to specify one unbound-
provided nameserver line (with 127.0.0.1 in there) and *add* the
dhcp-provided nameservers there *too*. And you don't want in this
case to enable unbound's resolvconf integration.

But this doesn't really work and it is unreliable.  Because quite
some software will query *all* nameservers listed in resolv.conf
at the same time (accepting the first reply), and some software
will only query the first one.

/mjt

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-19 13:22:53 +0300, Michael Tokarev wrote:
> In my understanding over the years, I expected the nameservers
> received from/by DHCP should be used *first*. I did this with
> unbound or dnsmasq even before resolvconf has been written -
> using custom dhcp script to reconfigure local DNS resolver.
> 
> I don't even know unbund has a way to specify "fallback"
> nameservers. You either set forwarders for a zone or you don't,
> there's no _notion_ of fallback per se.

The fallback is what resolvconf expects and precisely why
bug 1003135 was reassigned from resolvconf to unbound:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003135#40

  "In fact, unbound comes with resolvconf integration, so it should
  know about other nameservers coming from DHCP. [...]"

Note: resolvconf filters out nameservers coming from DHCP only those
that are placed after 127.0.0.1, i.e. those that are normally used as
a fallback when resolvconf isn't installed, because it assumes that
this fallback is provided by the local nameserver (here, unbound).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Michael Tokarev]

19.04.2022 13:09, Vincent Lefevre wrote:
...> The way resolvconf expects it to work is to use the usual method,

and in case of an error, fall back to the upstream nameservers.

Since the upstream nameservers should be used as a fallback, I don't
see why this would be problematic.


hm.. now this is interesting.

In my understanding over the years, I expected the nameservers
received from/by DHCP should be used *first*. I did this with
unbound or dnsmasq even before resolvconf has been written -
using custom dhcp script to reconfigure local DNS resolver.

I don't even know unbund has a way to specify "fallback"
nameservers. You either set forwarders for a zone or you don't,
there's no _notion_ of fallback per se.

Now I wonder if my understanding is completely out of this world..

/mjt

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-18 10:26:46 +0300, Michael Tokarev wrote:
> On Wed, 19 Jan 2022 16:33:46 +0100 Vincent Lefevre  wrote:
> > Package: unbound
> > Version: 1.13.1-1
> > Severity: important
> > 
> > Note: The changes I've done on /etc/resolvconf/update.d/unbound
> > is just logging messages (to known what's going on).
> > 
> > When /run/resolvconf/interface/NetworkManager is obsolete (which
> > can occur as NetworkManager is not the only was to connect: I use
> > it only for wifi), DNS resolution no longer works.
> > 
> > I fear that even when this file is not obsolete, unbound does not
> > work as expected.
> 
> Well, this file is *disabled*.

But the fact that it is disabled is a bug:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003135

> We added a note to this file telling just that, to clarify:
> 
> +# This update hook is **disabled** by default: the execute bit is not set.
> +#
> +# This hook can be problematic, especially if the
> +# upstream nameservers do not perform DNSSEC validation, or if a
> +# "forward-zone" declaration for the root zone has been statically
> +# configured by the administrator. In previous versions, the hook was
> +# enabled by default, but it is now disabled by default. It can be
> +# explicitly enabled by running "chmod +x /etc/resolvconf/update.d/unbound".
> +#
> +# If enabled (by setting the execute bit), upstream nameservers
> +# supplied by resolvconf will be configured into the running Unbound instance
> +# via the "unbound-control forward" command.
> +#
> 
> But besides that, what exactly do *you* think is buggy about it?

The way resolvconf expects it to work is to use the usual method,
and in case of an error, fall back to the upstream nameservers.

Since the upstream nameservers should be used as a fallback, I don't
see why this would be problematic.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Michael Tokarev]

On Wed, 19 Jan 2022 16:33:46 +0100 Vincent Lefevre  wrote:

Package: unbound
Version: 1.13.1-1
Severity: important

Note: The changes I've done on /etc/resolvconf/update.d/unbound
is just logging messages (to known what's going on).

When /run/resolvconf/interface/NetworkManager is obsolete (which
can occur as NetworkManager is not the only was to connect: I use
it only for wifi), DNS resolution no longer works.

I fear that even when this file is not obsolete, unbound does not
work as expected.


Well, this file is *disabled*. We added a note to this file telling
just that, to clarify:

+#
+# This update hook is **disabled** by default: the execute bit is not set.
+#
+# This hook can be problematic, especially if the
+# upstream nameservers do not perform DNSSEC validation, or if a
+# "forward-zone" declaration for the root zone has been statically
+# configured by the administrator. In previous versions, the hook was
+# enabled by default, but it is now disabled by default. It can be
+# explicitly enabled by running "chmod +x /etc/resolvconf/update.d/unbound".
+#
+# If enabled (by setting the execute bit), upstream nameservers
+# supplied by resolvconf will be configured into the running Unbound instance
+# via the "unbound-control forward" command.
+#

But besides that, what exactly do *you* think is buggy about it?

Thanks,

/mjt

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

Package: unbound
Version: 1.13.1-1
Severity: important

Note: The changes I've done on /etc/resolvconf/update.d/unbound
is just logging messages (to known what's going on).

When /run/resolvconf/interface/NetworkManager is obsolete (which
can occur as NetworkManager is not the only was to connect: I use
it only for wifi), DNS resolution no longer works.

I fear that even when this file is not obsolete, unbound does not
work as expected.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unbound depends on:
ii  adduser 3.118
ii  dns-root-data   2021011101
ii  libc6   2.33-2
ii  libevent-2.1-7  2.1.12-stable-1
ii  libprotobuf-c1  1.3.3-1+b2
ii  libpython3.93.9.10-1
ii  libssl1.1   1.1.1m-1
ii  libsystemd0 250.2-3
ii  lsb-base11.1.0
ii  openssl 1.1.1m-1
ii  unbound-anchor  1.13.1-1

unbound recommends no packages.

Versions of packages unbound suggests:
ii  apparmor  3.0.3-6

-- Configuration Files:
/etc/resolvconf/update.d/unbound changed:
PATH=/usr/sbin:/usr/bin:/sbin:/bin
if [ ! -x /usr/sbin/unbound ]; then
exit 0
fi
if [ ! -f /etc/unbound/unbound_control.key ]; then
exit 0
fi
if [ ! -x /lib/resolvconf/list-records ]; then
exit 1
fi
RESOLVCONF_FILES="$(/lib/resolvconf/list-records)"
if [ -n "$RESOLVCONF_FILES" ]; then
NS_IPS="$(sed -rne 's/^[[:space:]]*nameserver[[:space:]]+//p' 
$RESOLVCONF_FILES \
| egrep -v '^(127\.|::1)' | sort -u)"
else
NS_IPS=""
fi
if [ -n "$NS_IPS" ]; then
FWD="$(echo $NS_IPS | tr '\n' ' ')"
else
FWD=off
fi
logger "/etc/resolvconf/update.d/unbound: forward $FWD"
unbound-control forward $FWD 1>/dev/null 2>&1 || true


-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)