[PATCH v5 1/2] resolv: implement ipv4+ipv6 flags in resolv.conf (bug 30544)

[Florian Weimer]

* Petr Menšík:

> Do you know any nss module, which is using _res.options parsed by
> glibc and would use information provided in /etc/resolv.conf?

Historically, it used in some cases to change behavior when
RES_USE_INET6 was set.  Here's an example from code that's clearly
outside glibc (unlike say nss-altfiles, which was originally copied from
glibc sources):

<https://arthurdejong.org/git/nss-pam-ldapd/tree/nslcd/host.c?id=432cb4f71939e9675f9e29a610124a2cd687352b#n210>

This also shows why the _res.options interface is problematic: as far as
I can tell, this is on the daemon side (the d part) of the codebase.
This means that application-specific resolver settings via RES_OPTIONS
(or direct _res.options changes) do not influence the resolution
behavior.

> Many programs parse /etc/resolv.conf themselves and do not use any
> glibc interface for it, just fopen (). That is true to bind utilities
> like dig or host. For unbound-host tool as well, drill from ldns. In
> general, anything using DNS exclusively, like c-ares library, adns,
> ldns, unbound-libs...

Why would a DNS library change its processing logic based on the
setting?  Even the otherwise rather high-level Unbound library seems
pretty much tied to a specific address type.

The low level glibc APIs do not react to this flag, either:

+/* res_send-like modes do not perform error translation.  */

> Yes, they can implement similar change if they wish in their parsers
> and I would recommend it to them. The only nsswitch plugin doing DNS
> resolution outside libc's dns is resolve from systemd-resolved.

Ahh, so you want a different address policy for (unicast) DNS and for
other name resolution services such as LDAP?  This seems rather
specialized to me.

> If for example NetworkManager should manage these flags, it would have
> to pass information about it to whatever manages
> /etc/resolv.conf. From end applications it should not differ. This is
> change of dns nsswitch plugin only. If they use different module, it
> may have different preferences.

Isn't this in argument in favor of NetworkManager managing /etc/gai.conf
directly?

On the other hand, it seems that NetworkManager can get much the same
effect if it creates a route with an unreachable type.  From what I've
seen, the way this is generally expected to work (‘happy eyeballs’) is
that we produce an abundance of addresses, the application attempts
parallel non-blocking connect to a few of them, and the network is
supposed to provide ICMP error responses (preferably on ingress) if it
encounters an unsupported address family/address scope.  NetworkManager
creating routes to express that if available networks do not provide
this behavior natively looks like an acceptable workaround to me.

> I wrote it before. I want getent ahosts example.local to still return
> both addresses for link local protocols like nss-mdns plugin. It
> should provide also both addresses for localhost or other /etc/hosts
> entries. Even if options ipv4 in resolv.conf should prevent getent
> ahosts example.org from fetching and printing AAAA address. Because
> link-local protocol can use AAAA address it receives (including link
> scope_id) and is able to make communication with it. I think there
> should not be any other module accessing _res.options. If they have
> resolv.conf parser, they should parse it from text form instead. I
> would not oppose making _res internal only and static in libc.

See above, I don't see the need to filter out addresses if there is
prompt notification of unreachability.

The existing noaaaa option is intended as a debugging tool in case
someone claims that the extra AAAA queries cause problems.  With it you
can set noaaaa, observe that the problem persists, and move on.  It was
never intended as the start of a general policy engine for nss_dns.

Thanks,
Florian