You’re right: glibc seems to treat the absence of libnss-resolve itself as UNAVAIL, which is the same code returned on DNSSEC validation failures when libnss-resolve is working. I don’t see a way around this other than patching libnss-resolve to return NOTFOUND (or TRYAGAIN?) on validation failure.
It looks like there may be other ways for an active attacker to force a TRYAGAIN code (with a response that doesn’t fit in the caller-provided buffer), which suggests that the right configuration is [!UNAVAIL=return], not merely [NOTFOUND=return]. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1624071 Title: libnss-resolve: Fallback from resolve to dns breaks DNSSEC validation Status in systemd package in Ubuntu: Triaged Bug description: The libnss-resolve postinst script inserts ‘resolve’ before ‘dns’ in the hosts line of /etc/nsswitch.conf. This makes DNSSEC validation impossible, even with DNSSEC=yes in /etc/systemd/resolved.conf, because if libnss_resolve returns a validation failure, glibc will simply fall back to libnss_dns. It also makes NXDOMAIN lookups twice as slow. The following syntax would preserve the fallback in the case that systemd-resolved is not running at all, but allow systemd-resolved to fail lookups that should fail when it is running: hosts: files resolve [!TRYAGAIN=return] dns To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624071/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
