Bug#1003135: resolvconf: prevents wifi.sncf from being resolved

[Vincent Lefevre]

Package: resolvconf
Version: 1.90
Severity: important

In SNCF trains in France, the use of resolvconf prevents wifi.sncf
from being resolved. The issue seems to be that it is a local address,
thus it needs to use the nameserver provided by the DHCP server.

Removing the /etc/resolv.conf symlink (thus disabling resolvconf) and
reconnecting solves the issue.

FYI, something like the following is what is expected:

nameserver 127.0.0.1
nameserver 10.9.0.4

-- 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 resolvconf depends on:
ii debconf [debconf-2.0] 1.5.79
ii lsb-base 11.1.0

resolvconf recommends no packages.

resolvconf suggests no packages.

-- debconf information:
resolvconf/reboot-recommended-after-removal:
resolvconf/link-tail-to-original: false
resolvconf/downup-interfaces:
resolvconf/linkify-resolvconf: true

--
Vincent Lefèvre <vin...@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)

[Andrej Shadura]

Hi,

On Tue, 4 Jan 2022, at 18:33, Vincent Lefevre wrote:
> In SNCF trains in France, the use of resolvconf prevents wifi.sncf
> from being resolved. The issue seems to be that it is a local address,
> thus it needs to use the nameserver provided by the DHCP server.
>
> Removing the /etc/resolv.conf symlink (thus disabling resolvconf) and
> reconnecting solves the issue.
>
> FYI, something like the following is what is expected:
>
> nameserver 127.0.0.1
> nameserver 10.9.0.4

Thanks for the bug report. Can you please provide more information? Similar setups elsewhere work and use the nameservers provided by DHCP, I’m not sure why this one wouldn’t.

--
Cheers,
Andrej

[Andrej Shadura]

Hi,

On Tue, 4 Jan 2022, at 19:26, Vincent Lefevre wrote:
> With resolvconf disabled, I get
>
> nameserver 127.0.0.1
> nameserver 10.9.0.4
>
> where 127.0.0.1 is added by dhclient thanks to
>
> prepend domain-name-servers 127.0.0.1;

Why do you have this? This basically overrides the DHCP server by directing queries to your localhost DNS.

> Concerning resolvconf:
>
> /run/resolvconf/resolv.conf contains the following:
>
> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
> # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
> # 127.0.0.53 is the systemd-resolved stub resolver.
> # run "resolvectl status" to see details about the actual nameservers.
>
> nameserver 127.0.0.1
> search home
>
> /run/resolvconf/interface/lo.unbound contains:
>
> nameserver 127.0.0.1

This is correct: when you run a DNS server at localhost, you don’t usually want queries to slip to the network.

> I have not modified the resolvconf settings: I expect that it should
> work by default.

I would think this might be a bug in unbound, but since you report that the DHCP-provided DNS works when both nameserver lines are in, I think you probably don’t have unbound running, and you likely have not purged its configuration when you removed it.

Localhost should not be the first entry in your resolv.conf if you want to be able to use other DNS servers.

--
Cheers,
Andrej

[Vincent Lefevre]

On 2022-01-04 19:04:46 +0100, Andrej Shadura wrote:
> Thanks for the bug report. Can you please provide more information?
> Similar setups elsewhere work and use the nameservers provided by
> DHCP, I’m not sure why this one wouldn’t.

Also note that the issue seems more or less specific to SNCF (well,
I'm not sure whether similar issues can be seen elsewhere):

https://twitter.com/r1rail/status/682553600434946049

(this is from year 2015).

So, without resolvconf, this works for me in a degraded way.
But with resolvconf, this doesn't work at all.

[Vincent Lefevre]

On 2022-01-04 19:04:46 +0100, Andrej Shadura wrote:

> Thanks for the bug report. Can you please provide more information?
> Similar setups elsewhere work and use the nameservers provided by
> DHCP, I’m not sure why this one wouldn’t.

With resolvconf disabled, I get

nameserver 127.0.0.1
nameserver 10.9.0.4

where 127.0.0.1 is added by dhclient thanks to

prepend domain-name-servers 127.0.0.1;

in its /etc/dhcp/dhclient.conf configuration file. So I suppose that
"nameserver 10.9.0.4" comes from the DHCP server, which would make
sense as I get

$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.9.0.4 0.0.0.0 UG 600 0 0 wlp61s0
10.9.0.0 0.0.0.0 255.255.240.0 U 600 0 0 wlp61s0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 wlp61s0

Concerning resolvconf:

/run/resolvconf/resolv.conf contains the following:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

nameserver 127.0.0.1
search home

/run/resolvconf/interface/lo.unbound contains:

nameserver 127.0.0.1

I have not modified the resolvconf settings: I expect that it should
work by default.

[Andrej Shadura]

Hi,

On Tue, 4 Jan 2022, at 19:37, Vincent Lefevre wrote:
> Also note that the issue seems more or less specific to SNCF (well,
> I'm not sure whether similar issues can be seen elsewhere):
>
> https://twitter.com/r1rail/status/682553600434946049
>
> (this is from year 2015).
>
> So, without resolvconf, this works for me in a degraded way.
> But with resolvconf, this doesn't work at all.

As I said in the other email, it seems from your report that resolvconf is doing its job just as expected, but your network configuration is not intact, leading to this observed result.

--
Cheers,
Andrej

[Vincent Lefevre]

On 2022-01-04 19:33:14 +0100, Andrej Shadura wrote:
> On Tue, 4 Jan 2022, at 19:26, Vincent Lefevre wrote:
> > With resolvconf disabled, I get
> >
> > nameserver 127.0.0.1
> > nameserver 10.9.0.4
> >
> > where 127.0.0.1 is added by dhclient thanks to
> >
> > prepend domain-name-servers 127.0.0.1;
>
> Why do you have this? This basically overrides the DHCP server by
> directing queries to your localhost DNS.

One reason is that because ISPs may block websites via DNS (for good
or bad reasons). For instance: https://www.soundofscience.fr/1723
(article in French). So I prefer to bypass the DNS servers of the ISP
if this works, and use them only in case of failure (the issue with
SNCF wifi, probably because it filters UDP[*], is an example).

[*] BTW, there's also a Parisian university that filters UDP for its
wifi hotspot (which prevents mosh and NTP from working), so SNCF may
not be the only case when there would be issues with resolvconf.

> > /run/resolvconf/interface/lo.unbound contains:
> >
> > nameserver 127.0.0.1
>
> This is correct: when you run a DNS server at localhost, you don’t
> usually want queries to slip to the network.

No, this is not. I have specifically configured my DHCP client to
use the provided DNS servers as a fallback. If I did not want that,
I would have removed "domain-name-servers" from its configuration.

Said otherwise, resolvconf should honor the configuration of the
DHCP client.

> > I have not modified the resolvconf settings: I expect that it should
> > work by default.
>
> I would think this might be a bug in unbound, but since you report
> that the DHCP-provided DNS works when both nameserver lines are in,
> I think you probably don’t have unbound running, and you likely have
> not purged its configuration when you removed it.

See above for the reason I use unbound. And I don't think that
unbound can do anything, as it doesn't know the concept of
servers provided by DHCP.

> Localhost should not be the first entry in your resolv.conf if you
> want to be able to use other DNS servers.

ISPs are likely to redirect blocked domains/hosts to a different host
(e.g. so that the user can get the reason of the blocking). So this
would not work. Anyway, if I wanted to use localhost as a fallback,
I would not have used "prepend", but "append" in dhclient.conf.

[Andrej Shadura]

On Wed, 5 Jan 2022, at 09:56, Andrej Shadura wrote:
> to work, I think it’s worth reassigning this package to unbound because

I meant "reassigning this bug", of course 🙂

--
Cheers,
Andrej

[Andrej Shadura]

Hi again,

On Wed, 5 Jan 2022, at 09:56, Andrej Shadura wrote:

> In fact, unbound comes with resolvconf integration, so it should know
> about other nameservers coming from DHCP. It is likely that the fact
> you add 127.0.0.1 in front of them is preventing that integration from
> working properly. Or maybe it’s a bug.

I just wanted to clarify: unbound already puts itself (as 127.0.0.1) first in resolvconf configuration. You should not need to modify you DHCP client’s configuration to add it once more. Unbound’s resolvconf integration should theoretically filter 127.0.0.1 out and tell unbound to forward its requests to your network’s name servers, but for some reason it doesn’t. Or maybe you’ve modified unbound’s configuration to disallow that.

--
Cheers,
Andrej

[Andrej Shadura]

Control: reassign -1 src:unbound

Hi,

On Wed, 5 Jan 2022, at 00:26, Vincent Lefevre wrote:
>> > where 127.0.0.1 is added by dhclient thanks to
>> >
>> > prepend domain-name-servers 127.0.0.1;
>>
>> Why do you have this? This basically overrides the DHCP server by
>> directing queries to your localhost DNS.
>
> One reason is that because ISPs may block websites via DNS (for good
> or bad reasons). For instance: https://www.soundofscience.fr/1723
> (article in French). So I prefer to bypass the DNS servers of the ISP
> if this works, and use them only in case of failure (the issue with
> SNCF wifi, probably because it filters UDP[*], is an example).

<..>

> See above for the reason I use unbound. And I don't think that
> unbound can do anything, as it doesn't know the concept of
> servers provided by DHCP.

In fact, unbound comes with resolvconf integration, so it should know about other nameservers coming from DHCP. It is likely that the fact you add 127.0.0.1 in front of them is preventing that integration from working properly. Or maybe it’s a bug.

In any case, even though I still think what you’re doing isn’t supposed to work, I think it’s worth reassigning this package to unbound because it’s possible that it can be fixed there.

--
Cheers,
Andrej

[Vincent Lefevre]

Control: found -1 1.13.1-1

Hi,

On 2022-01-05 09:56:26 +0100, Andrej Shadura wrote:
> In fact, unbound comes with resolvconf integration, so it should
> know about other nameservers coming from DHCP. It is likely that the
> fact you add 127.0.0.1 in front of them is preventing that
> integration from working properly. Or maybe it’s a bug.

The unbound(8) man page says

To use a locally running Unbound for resolving put

nameserver 127.0.0.1

into resolv.conf(5).

Since resolv.conf is under the control of dhclient, I did that
via the dhclient configuration file.

I now see the /etc/resolvconf/update.d/unbound file (this was not
documented). It runs /lib/resolvconf/list-records, so I'll see
what I get. I'm no longer in the train, so I won't be able to
test hostname resolution, but I could see whether the knowledge
of other DHCP-provided nameservers gets in $FWD in this script.

If I understand how this should work with resolvconf + unbound:

* /etc/resolv.conf should contain only 127.0.0.1 (corresponding
to unbound).

* /lib/resolvconf/list-records should output lines with 127.0.0.1
and the DHCP-provided nameservers.

* /etc/resolvconf/update.d/unbound makes unbound aware of these
DHCP-provided nameservers.

I'll see whether I get this (I don't have my laptop with me here).
If I do, then yes, this could be a bug in unbound. I'm not sure,
though, because the unbound-control(8) man page is not very detailed.
It says in particular:

If off is passed, forwarding is disabled and the root nameservers
are used. This can be used to avoid to avoid buggy or non-DNSSEC
supporting nameservers returned from DHCP. But may not work in
hotels or hotspots.

I'm precisely in the case of buggy nameservers returned from DHCP!
So it appears that what the /etc/resolvconf/update.d/unbound script
does may be wrong! What I want is to use the root nameservers by
default, and the nameservers returned from DHCP as a fallback
(e.g. for "hotels or hotspots", like in the train), as described
in the resolv.conf(5) man page: "If there are multiple servers,
the resolver library queries them in the order listed." But it is
also possible that the unbound-control(8) man page is inaccurate
and misleading.

BTW, in the train, it is also possible that this wasn't working
due to bad coincidence, since the network wasn't very good and
there could be failures due to that. But I had tried several
times, and this began to work only after I replaced resolv.conf
to have the DHCP-provided nameserver there (after 127.0.0.1).

[Vincent Lefevre]

On 2022-01-05 10:04:38 +0100, Andrej Shadura wrote:
> I just wanted to clarify: unbound already puts itself (as 127.0.0.1)
> first in resolvconf configuration. You should not need to modify you
> DHCP client’s configuration to add it once more. Unbound’s
> resolvconf integration should theoretically filter 127.0.0.1 out and
> tell unbound to forward its requests to your network’s name servers,
> but for some reason it doesn’t. Or maybe you’ve modified unbound’s
> configuration to disallow that.

After testing, /etc/resolvconf/update.d/unbound isn't run at all:
I've added "logger /etc/resolvconf/update.d/unbound" at the beginning
of this script, and it doesn't appear in the logs.

So this seems to be a resolvconf bug.

[Andrej Shadura]

Hi,

On Wed, 5 Jan 2022, at 15:17, Vincent Lefevre wrote:
> What happens with unbound is that /run/resolvconf/resolv.conf
> *always* contains "nameserver 127.0.0.1", i.e. this file never
> changes, even though the DHCP-provided nameservers (which are
> not listed in this file) do. So putting the unbound hook script
> in this /etc/resolvconf/update-libc.d directory is very silly!

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.

--
Cheers,
Andrej

[Vincent Lefevre]

On 2022-01-05 15:11:04 +0100, Vincent Lefevre wrote:
> After testing, /etc/resolvconf/update.d/unbound isn't run at all:
> I've added "logger /etc/resolvconf/update.d/unbound" at the beginning
> of this script, and it doesn't appear in the logs.
>
> So this seems to be a resolvconf bug.

Well, perhaps not. The resolvconf(8) man page says:

When nameserver information is updated, the script
/etc/resolvconf/update.d/libc generates a new version of the
resolver configuration file, /run/resolvconf/resolv.conf, as
described below. If the new version of the file differs from
the previously generated one then the hook scripts found in
/etc/resolvconf/update-libc.d/ are executed.

What happens with unbound is that /run/resolvconf/resolv.conf
*always* contains "nameserver 127.0.0.1", i.e. this file never
changes, even though the DHCP-provided nameservers (which are
not listed in this file) do. So putting the unbound hook script
in this /etc/resolvconf/update-libc.d directory is very silly!

[Vincent Lefevre]

On 2022-01-05 15:22:55 +0100, Andrej Shadura wrote:
> Hi,
>
> On Wed, 5 Jan 2022, at 15:17, Vincent Lefevre wrote:
> > What happens with unbound is that /run/resolvconf/resolv.conf
> > *always* contains "nameserver 127.0.0.1", i.e. this file never
> > changes, even though the DHCP-provided nameservers (which are
> > not listed in this file) do. So putting the unbound hook script
> > in this /etc/resolvconf/update-libc.d directory is very silly!

Oops, I forgot /etc/resolvconf/update.d/unbound, but it isn't run
either, even if the nameservers change, e.g. from

zira:~> cat /run/resolvconf/interface/NetworkManager
nameserver 127.0.0.1
nameserver 192.168.43.31

to

zira:~> cat /run/resolvconf/interface/NetworkManager
nameserver 127.0.0.1
nameserver 192.168.1.1

So this may be a bug in resolvconf after all, since this script
is supposed to be run when nameserver information has changed.

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

[Vincent Lefevre]

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 Lefevre]

[Another update to clarify, sorry, I mixed up two related issues, one
about postfix name resolution and one about resolvconf + unbound.]

On 2022-01-05 15:34:38 +0100, Vincent Lefevre wrote:

> On 2022-01-05 15:22:55 +0100, Andrej Shadura wrote:
> > On Wed, 5 Jan 2022, at 15:17, Vincent Lefevre wrote:
> > > What happens with unbound is that /run/resolvconf/resolv.conf
> > > *always* contains "nameserver 127.0.0.1", i.e. this file never
> > > changes, even though the DHCP-provided nameservers (which are
> > > not listed in this file) do. So putting the unbound hook script
> > > in this /etc/resolvconf/update-libc.d directory is very silly!

/etc/resolvconf/update-libc.d actually just contains the postfix
hook script, which is correct. The unbound hook script is just in
/etc/resolvconf/update.d, which is also correct. So the only issue
is the following, i.e. the fact that the unbound hook script is
not run when the nameservers provided by DHCP (via NetworkManager)
change:

> Oops, I forgot /etc/resolvconf/update.d/unbound, but it isn't run
> either, even if the nameservers change, e.g. from
>
> zira:~> cat /run/resolvconf/interface/NetworkManager
> nameserver 127.0.0.1
> nameserver 192.168.43.31
>
> to
>
> zira:~> cat /run/resolvconf/interface/NetworkManager
> nameserver 127.0.0.1
> nameserver 192.168.1.1
>
> So this may be a bug in resolvconf after all, since this script
> is supposed to be run when nameserver information has changed.

[Vincent Lefevre]

On 2022-01-05 15:56:33 +0100, Andrej Shadura wrote:
> Hi,
>

> On Wed, 5 Jan 2022, at 15:34, Vincent Lefevre wrote:
> > Oops, I forgot /etc/resolvconf/update.d/unbound, but it isn't run
> > either, even if the nameservers change, e.g. from
> >
> > zira:~> cat /run/resolvconf/interface/NetworkManager
> > nameserver 127.0.0.1
> > nameserver 192.168.43.31
> >
> > to
> >
> > zira:~> cat /run/resolvconf/interface/NetworkManager
> > nameserver 127.0.0.1
> > nameserver 192.168.1.1
> >
> > So this may be a bug in resolvconf after all, since this script
> > is supposed to be run when nameserver information has changed.
>

> By default resolvconf truncates on localhost, so the resulting file
> doesn’t change. I guess I need to give it a bit more though.

This means that the hook scripts in /etc/resolvconf/update-libc.d
will not be run. But the hook scripts in /etc/resolvconf/update.d
should still be run, as documented in the resolvconf(8) man page.

I can see:

zira:~> ll /etc/resolvconf/update.d
total 12
-rwxr-xr-x 1 root root 4641 2021-12-28 22:36:01 libc*
-rw-r--r-- 1 root root 661 2022-01-05 15:36:36 unbound

While "libc" is executable, "unbound" is not. This may be the cause
of the bug (the resolvconf(8) man page is not explicit about the
behavior). I'm going to do some tests.

> In any case though, you probably shouldn’t prepend localhost in your
> DHCP config, but rely on unbound’s integration instead.

This is needed if resolvconf is not installed. This is not the
cause of the bug, anyway.

[Vincent Lefevre]

On 2022-01-05 16:10:50 +0100, Vincent Lefevre wrote:
> On 2022-01-05 15:56:33 +0100, Andrej Shadura wrote:
> I can see:
>
> zira:~> ll /etc/resolvconf/update.d
> total 12
> -rwxr-xr-x 1 root root 4641 2021-12-28 22:36:01 libc*
> -rw-r--r-- 1 root root 661 2022-01-05 15:36:36 unbound
>
> While "libc" is executable, "unbound" is not. This may be the cause
> of the bug (the resolvconf(8) man page is not explicit about the
> behavior). I'm going to do some tests.

Indeed, this was the cause of the issue. After making unbound
executable, I now get:

# unbound-control forward
192.168.43.173 192.168.1.1

instead of "off".

However, this is broken: 192.168.1.1 shouldn't be there!!!

FYI:

zira:~> cat /run/resolvconf/interface/NetworkManager
nameserver 127.0.0.1

nameserver 192.168.43.173

Where does 192.168.1.1 come from?

Perhaps /run/resolvconf/interface/original.resolvconf, which contains

# Generated by NetworkManager
nameserver 127.0.0.1
nameserver 192.168.1.1

So, in short, there seems to be 2 bugs:

1. One in unbound: /etc/resolvconf/update.d/unbound is not executable.

2. One in resolvconf, which adds an obsolete original.resolvconf in
/run/resolvconf/interface (no mention of it in the resolvconf(8)
man page).

Moreover, the resolvconf(8) man page should be improved about the
executable status of file in "/etc/resolvconf/update.d".

[Vincent Lefevre]

On 2022-01-05 16:12:52 +0100, Andrej Shadura wrote:
> unbound (1.5.7-2) unstable; urgency=medium
>
> * debian/rules: Disable the resolvconf update.d hook by default
>
> I guess this is it. No idea why, no explanation.

Probably. In any case, having the hook script installed, but silently
disabled will confuse many people!

But I don't see why it should be disabled: if the users do not want
the DHCP-provided servers as a fallback, they can just configure the
DHCP client not to accept these servers.

[Vincent Lefevre]

On 2022-01-05 16:28:21 +0100, Vincent Lefevre wrote:
> On 2022-01-05 16:12:52 +0100, Andrej Shadura wrote:
> > unbound (1.5.7-2) unstable; urgency=medium
> >
> > * debian/rules: Disable the resolvconf update.d hook by default
> >
> > I guess this is it. No idea why, no explanation.
>
> Probably. In any case, having the hook script installed, but silently
> disabled will confuse many people!
>
> But I don't see why it should be disabled: if the users do not want
> the DHCP-provided servers as a fallback, they can just configure the
> DHCP client not to accept these servers.

/usr/share/doc/unbound/NEWS.Debian.gz, in 2016:

The resolvconf update.d 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".

But I don't understand. The upstream nameservers are supposed to be
used as a fallback. Even if upstream nameservers do not perform DNSSEC
validation, this is still better than a failure when DNSSEC is not
required.

[Vincent Lefevre]

Control: reassign -1 unbound 1.13.1-1
Control: retitle -1 unbound: /etc/resolvconf/update.d/unbound should be reenabled by default

The unbound behavior should be similar to the one without
resolvconf installed. So /etc/resolvconf/update.d/unbound
should be reenabled by default so that name resolution works
when UDP is filtered, and perhaps more generally to make it
work with captive portals, which are common nowadays.

The current situation is very confusing, and the installation
of resolvconf (e.g. because some other package needs it) may
make things no longer work as expected.

On 2022-01-05 16:22:16 +0100, Vincent Lefevre wrote:
> Indeed, this was the cause of the issue. After making unbound
> executable, I now get:
>
> # unbound-control forward
> 192.168.43.173 192.168.1.1
>
> instead of "off".
>
> However, this is broken: 192.168.1.1 shouldn't be there!!!

Concerning this issue, this is because a reboot was needed, as
documented in the resolvconf(8) man page (I think that resolvconf
should have been smarter, but this is probably not a big issue).

[Michael Tokarev]

On Wed, 5 Jan 2022 16:36:40 +0100 Vincent Lefevre <vin...@vinc17.net> wrote:
..

> But I don't understand. The upstream nameservers are supposed to be
> used as a fallback. Even if upstream nameservers do not perform DNSSEC
> validation, this is still better than a failure when DNSSEC is not
> required.

For the record, this is incorrect, just like has been stated in #1004032
numerous times already.

The upstream nameservers provided by DHCP were never supposed to be used
as a "fallback", even more, there's no _notion_ of a "fallback" in this
context.

We EITHER use the DHCP-provided nameservers, OR we use the regular recursive
way. But not both.

I know no recursive resolver software which has notion of "fallback" like
this.

Thanks,

/mjt

[Vincent Lefevre]

Without resolvconf installed, it appears to work: if unbound cannot
resolv the hostname, then the next nameserver in /etc/resolv.conf is
used.

For instance, I currently have in /etc/resolv.conf:

nameserver 127.0.0.1
nameserver 192.168.1.1

If I stop unbound, then I still get hostname resolution. But if I only
have

nameserver 127.0.0.1

and unbound is stopped, then hostname resolution no longer works.
This shows that 192.168.1.1 is used as a fallback.

And something like "strace wget ... |& grep sin_addr=inet_addr" also
confirms this behavior.

[Vincent Lefevre]

On 2022-04-20 01:21:23 +0300, Michael Tokarev wrote:

> 20.04.2022 00:55, Vincent Lefevre wrote:
> > If I stop unbound, then I still get hostname resolution. But if I only
> > have
> >
> > nameserver 127.0.0.1
> >
> > and unbound is stopped, then hostname resolution no longer works.
> > This shows that 192.168.1.1 is used as a fallback.
>

> So this is all about resolvconf: it should have a way to treat some
> nameservers as "fallback-only" and not propagate them to local nameservers.

Yes, I recall that I initially reported the bug against resolvconf.
But Andrej Shadura eventually reassigned it to unbound, implying
that unbound was doing that with its resolvconf integration. So
this is really confusing.