On 2022-04-18 10:26:46 +0300, Michael Tokarev wrote: > On Wed, 19 Jan 2022 16:33:46 +0100 Vincent Lefevre <vinc...@vinc17.net> 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 <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
