I've had a debugging session with @cpaelzer earlier today, where we ran into some "Temporary failure in name resolution" issues inside a KVM guest (for all - even global - domains) and "resolvectl dnssec enp1s0 false" made it work, which was scary. – But we fiddled quite a bit with the host networking, too.
Trying to reproduce this libvirt/KVM issue on a clean Noble host and Questing guest, everything worked as expected. In libvirt/Qemu we don't have a private zone defined: $ cat /etc/resolv.conf [...] nameserver 127.0.0.53 options edns0 trust-ad search . In Multipass, we have the "multipass" domain defined, causing issues: $ cat /etc/resolv.conf [...] nameserver 127.0.0.53 options edns0 trust-ad search multipass => This can be worked around in a similar way as the LXD workaround, using a negative trust-anchor (see comment #9): $ cat /usr/lib/dnssec-trust-anchors.d/mp.negative multipass => But I did not find a way how to assign the Multipass project to this bug report on Launchpad. Will reach out to them individually. In LXD we have the "lxd" domain defined, causing issues: $ cat /etc/resolv.conf [...] nameserver 127.0.0.53 options edns0 trust-ad search lxd => Interestingly, after installing systemd 257.7-1ubuntu3 (incl. systemd-resolved-dnssec) and rebooting the LXD container/VM (I tried both), name resolution was working initially, even on the .lxd local name. In the journal log I found some interesting messages: """ Aug 26 10:23:32 q1 systemd-resolved[112]: Using degraded feature set UDP instead of UDP+EDNS0+DO for DNS server 10.238.94.1. Aug 26 10:23:32 q1 systemd-resolved[112]: [🡕] Server 10.238.94.1 does not support DNSSEC, downgrading to non-DNSSEC mode. Aug 26 10:50:59 q1 systemd-resolved[112]: Grace period over, resuming full feature set (UDP+EDNS0+DO) for DNS server 10.238.94.1. Aug 26 10:50:59 q1 systemd-resolved[112]: Using degraded feature set UDP instead of UDP+EDNS0+DO for DNS server 10.238.94.1. """ systemd-resolved seems to correctly detect that the upstream dnsmasq server is not supporting DNSSEC and enabling the fallback (non-DNSSEC) mode. After a grace period of some 25 sec, it resets to full DNSSEC support and eventually downgrades again. This whole dance goes on for a while but eventually stops working, especially after a "systemctl restart systemd-resolved". So something seems to be wonky in systemd-resolved's detection of the upstream DNS server feature set and logic for activation of the fallback mode. Similar issues of feature detection, especially in "local" DNS servers (e.g. home routes or virtualization environments) have been described by upstream systemd some 5 years ago: * https://lists.fedoraproject.org/archives/list/[email protected]/message/AFHNUEHKC5KJVGBGSJBH2BMESUAGDF4H/ * https://lists.fedoraproject.org/archives/list/[email protected]/message/P63RI3VBQ7NGL3AKMTR7PCVHVSCPYCLF/ It seems like this might still not be as reliable as we'd want it to be, and I'm pondering if we should downgrade that "Recommends: systemd- resolved-dnssec" to a "Suggests" after all... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2119652 Title: systemd-resolved-dnssec breaks name resolution on lxd domain To manage notifications about this bug go to: https://bugs.launchpad.net/lxd/+bug/2119652/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
