Thanks for reporting this, well spotted!
The reason for having "dns" is *not* to guard against failures of
resolved -- if the daemon is not running, then nss-resolve already falls
back to glibc's resolver (i. e. "dns").
The reason is that libnss-resolve itself might not be available. E. g.
you might have the amd64 version installed that inserts itself into
nsswitch. But then you start a 32 bit package from an i386 deb which
needs libnss-resolve:i386 and that might not be installed. That needs
"dns" otherwise you get a "System error" when resolving.
I actually thought that "resolve [NOTFOUND=return] dns" should do the
right thing, as that's the crucial case -- its default action is
"continue", and if a DNS entry fails validation we don't want to fall
back to "dns". The actions for success/unavail/tryagain already seem
right. But this doesn't work, "ping sigfail.verteiltesysteme.net" still
succeeds and falls back to dns.
So I'm not sure how to solve this. Ideally we would have a syntax which
would ignore the absence of the "resolve" NSS module but accept if that
says "not found". Or we need to ensure that for any :arch package the
corresponding libnss-resolve:arch is installed.
** Changed in: systemd (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1624071
Title:
libnss-resolve: Fallback from resolve to dns breaks DNSSEC validation
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624071/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
