[SOLVED] systemd-resolved weirdness

[mighty spindle]

So I have systemd-resolved in a debian 13 environment configured as following:

[Resolve]
DNS=8.8.8.8
DNSSEC=allow-downgrade
DNSOverTLS=opportunistic
DNSStubListener=yes
DNSStubListenerExtra=172.26.95.1
ReadEtcHosts=yes

Now the weird part. Immediately after startup, everything works fine. However after some time has passed the following symptoms begins:

1. everything that uses glibc resolver times out or hangs, so basically everything in the system doesnt work. (/etc/resolv.conf points to systemd-resolved's stub resolver)
2. resolvectl query works fine
3. specifying other dns server in nslookup works fine. Otherwise it tries to use the stub resolver on 127.0.0.53 which times out.
4. 127.0.0.54 works fine
5. Request from other machines in the subnet (as enabled with DNSStubListenerExtra=172.26.95.1) works fine

[carmine yacht]

Disable the default stub listener and use an explicit loopback IP

[Resolve]
DNS=8.8.8.8
DNSStubListener=no
DNSOverTLS=opportunistic
DNSSEC=allow-downgrade

Then point /etc/resolv.conf directly to 127.0.0.54 or your extra listener (172.26.95.1) instead of 127.0.0.53. This avoids glibc hangups.

[mighty spindle]

i guess thats a good workaround but

any idea why is the default stub resolver not working?

[carmine yacht]

It's because systemd-resolved’s stub socket can fail due to TLS/DNSSEC negotiation issues, network/interface changes, or socket conflicts, which hangs glibc-based lookups while resolvectl and other listeners keep working.

[mighty spindle]

oh alirght

[mighty spindle]

thank you for this information

[maiden kayak]

alpha_b_9 received a thank you cookie!