On a recent Arch Linux system, a user reports that their "hosts" line in
nsswitch.conf is:
hosts: files resolve myhostname
apparently libnss_resolve.so.2 is provided by systemd on that system, which
hooks into systemd-resolved somehow for implementation of gethostbyname and
getaddrinfo.
This is a legitimate and functional setup.
however, dirmngr's libdns parses this file and apparently tries to guess what
each configuration means, and has hard-coded understandings of what each
directive means.
in particular, dirmngr/dns.c hard-codes an understanding of these strings, which
do not contain either "myhostname" or "resolve":
static const char *list[] = {
[DNS_NSSCONF_HOSTS] = "hosts", [DNS_NSSCONF_SUCCESS] = "success", [DNS_NSSCONF_NOTFOUND] = "notfound", [DNS_NSSCONF_UNAVAIL] = "unavail", [DNS_NSSCONF_TRYAGAIN] = "tryagain", [DNS_NSSCONF_CONTINUE] = "continue", [DNS_NSSCONF_RETURN] = "return", [DNS_NSSCONF_FILES] = "files", [DNS_NSSCONF_DNS] = "dns", [DNS_NSSCONF_MDNS] = "mdns",
};
As a result, libdns doesn't have any directives to look up the keyserver's
address with, so it fails.
It would be better to try to not fail :) I see two approaches:
if libdns tries to parse nsswitch.conf and never finds a "dns" element in its
"hosts:" line:
0) it implicitly assumes that there is a "dns" lookup at the end of the list,
and tries again from there
- it falls back to "standard-resolver"
Both of these situations would have worked for this user (i believe they chose
to explicitly set "standard-resolver" in dirmngr.conf as a workaround).
in both cases, dirmngr should probably emit a warning that it libdns is
operating in some sort of fallback mode.