On Mon, Dec 14, 2020 at 11:01:36AM +, Dridi Boukelmoune wrote:
> > It looks like resolved tries to resolve the name on two scopes (global and
> > one specific to some interface). This will happen if the name lookup
> > priority
> > is the same for both the two scopes.
>
> Interesting, I'll se
> It looks like resolved tries to resolve the name on two scopes (global and
> one specific to some interface). This will happen if the name lookup priority
> is the same for both the two scopes.
Interesting, I'll search the docs. I don't recall seeing anything
about priority and that's definitely
On Sun, Dec 13, 2020 at 03:58:06PM +, Dridi Boukelmoune wrote:
> > That's totally on me, I read the resolved.conf(5) manual but didn't
> > pay attention to the systemd-resolved.service(8) manual in the SEE
> > ALSO section: that would have led me to resolvectl. Thanks for the
> > pointer, I'll
> The answers came quickly from address1, and were allegedly cached.
>
> Second bug? subsequent queries will still be cache misses.
Before anyone asks, I have Cache=yes in resolved.conf, I was at least
up to speed with the contents of the resolved.conf(5) manual.
Dridi
___
> That's totally on me, I read the resolved.conf(5) manual but didn't
> pay attention to the systemd-resolved.service(8) manual in the SEE
> ALSO section: that would have led me to resolvectl. Thanks for the
> pointer, I'll do some reading, probably figure what I mis-configured
> and otherwise file
> An unfinished dbus call should only happen when the server fails
> internally and aborts the connection. If there's an error or timeout in
> the query resolution, it should still terminate the connection with
> some response.
>
> Please enable debug logs with 'resolvectl log-level debug' and do t
On Tue, Dec 08, 2020 at 05:01:52PM +, Dridi Boukelmoune wrote:
> Greetings,
>
> I'm not sure whether I am doing something wrong so I'd rather get
> someone's opinion before submitting a bug report.
>
> Since the upgrade to f33 I replaced my stubby setup with
> systemd-resolved since it is now
On 12/10/20 7:16 PM, Paul Wouters wrote:
On Wed, 9 Dec 2020, Dridi Boukelmoune wrote:
This again leads to a required architecture change. We really need to
have a captive portal namespace, that handles all of this while the
applications still consider the network is down. Once the captive
portal
> Instead, we have gnome, NM, systemd-resolved, firefox et all fighting
> over who and how to handle captive portal authentication.
What bothers me first and foremost is that I'm not connecting through
a captive portal, and somehow I can't fully trust systemd-resolved to
DoTheRightThing(tm).
On p
On Wed, 9 Dec 2020, Dridi Boukelmoune wrote:
So it looks like my initial intuition that there could be a mitigation
of sorts is starting to hold water. The problem now is that clients on
my system using getaddrinfo in a way that was legit until now are now
being DoS'd by systemd-resolved, waitin
> I wouldn't mind the mitigation, if only I could disable it. Does
> anyone know any better? I'm still suspecting I configured something
> wrong but at the same time systemd seems to have a history with
> NXDOMAIN handling.
I found several things, including this related to NXDOMAIN:
https://githu
On Tue, Dec 8, 2020 at 8:34 PM Marius Schwarz wrote:
>
> Am 08.12.20 um 19:32 schrieb Dridi Boukelmoune:
> >
> >> Petr was so nice to supply a test procedure, i suggest that you use it
> >> also.
> > I'll try to strace stuff to to see what's going on, but I can only
> > assume that this BZ is not
Am 08.12.20 um 19:32 schrieb Dridi Boukelmoune:
Petr was so nice to supply a test procedure, i suggest that you use it also.
I'll try to strace stuff to to see what's going on, but I can only
assume that this BZ is not trying to resolve ip addresses through
systemd-resolved.
No, they didn'
> Can you pls get another stackframe and compare it ( it won't match 100%
> as differen apps go different way) with this bugreport:
It won't matter much, the next frame is in Varnish code.
Here is the pstack dump of dig:
> Thread 4 (Thread 0x7fee8a3e4640 (LWP 1768516) "isc-socket"):
> #0 0x
Am 08.12.20 um 18:01 schrieb Dridi Boukelmoune:
Since the upgrade to f33 I replaced my stubby setup with
systemd-resolved since it is now the default. I was OK with that
change since I didn't lose functionality compared to my previous
setup. But it is breaking getaddrinfo() and IP address resolut
Greetings,
I'm not sure whether I am doing something wrong so I'd rather get
someone's opinion before submitting a bug report.
Since the upgrade to f33 I replaced my stubby setup with
systemd-resolved since it is now the default. I was OK with that
change since I didn't lose functionality compare
16 matches
Mail list logo
