On 2022-01-05 15:34:38 +0100, Vincent Lefevre wrote:
> On 2022-01-05 15:22:55 +0100, Andrej Shadura wrote:
> > Having looked at it again, it seems Thomas, the original author of
> > resolvconf, have actually included a workaround for your use case.
> > Set TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=no in
> > /etc/default/resolvconf, and it should do the thing.
> 
> Well, the bug needs to be fixed to avoid the workaround.
> Or the workaround should be the default.

About the TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS
documentation, the resolvconf(8) man page says:

  The advantage of truncating the nameserver list after a loopback
  address is that doing so inhibits unnecessary changes to resolv.conf
  and thus reduces the number of instances in which the update-libc.d/
  scripts have to be run. When an interface is brought up or down the
  local caching nameserver that listens on the loopback address is
  still informed of the change and adapts accordingly; the clients of
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  the resolver which use the local caching nameserver do not need to
  be notified of the change. A disadvantage of this mode of operation
  is that applications have no secondary or tertiary nameserver
  address to fall back on should the local caching nameserver crash.
  Insofar as a local nameserver crash can be regarded as an unlikely
  event, this is a relatively minor disadvantage.

The issue I have is that the local caching nameserver (unbound)
is *not* informed of the change, because resolvconf does not run
/etc/resolvconf/update.d/unbound, contrary to what is documented.
The point of TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS is
to have a fallback in case of the crash of the local caching
nameserver, but there is no crash in my case, i.e. setting
TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS to "no" should
not be needed in my case.

-- 
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)

Reply via email to