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
On 2022-04-19 23:33:06 +0300, Michael Tokarev wrote:
> On Wed, 5 Jan 2022 16:36:40 +0100 Vincent Lefevre 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 bett
On Wed, 5 Jan 2022 16:36:40 +0100 Vincent Lefevre 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, th
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 resolu
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.
>
> Probabl
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
disabl
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 "l
On Wed, 5 Jan 2022, at 16:10, Vincent Lefevre wrote:
>> 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 i
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/NetworkManage
Hi,
On Wed, 5 Jan 2022, at 16:04, Vincent Lefevre wrote:
> 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
>> >
[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 wrot
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
>
> zir
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_AD
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 nameser
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 un
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, per
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 theoreticall
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 f
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 properl
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
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 lo
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;
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 resolv
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 (we
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
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
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.con
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 (t
28 matches
Mail list logo
