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

[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?

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...

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.

But that is not consument of /etc/resolv.conf usually. Instead, that is 
provider and generator of /etc/resolv.conf. Whatever is source of ipv4 
or ipv6 flag configuration, it would have to send such information to 
it. It should be possible to enable it just manual way. I won't 
implement this in systemd, but similar support in it would be nice.

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.

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.

We could offer int res_noptions(res_state statep) new function, 
returning RES_ flags currently used. But because we do not have nice 
export of /etc/resolv.conf nameserver entries in form of library call 
(which would be more useful IMO), I think it is up to other resolv.conf 
consuments to adjust too. If they don't, it will still work, but doing 
unnecessary queries.

On 15/10/2025 22:05, Florian Weimer wrote:
> These should be /etc/gai.conf options.  This means that we get extra
> queries for IPv6 mode (which has to use gethostnameby4 if AAAA lookups
> are requested even if A lookups are disabled).  We can disable those for
> the internal dns module through an internal interface, but it won't help
> external NSS modules.  For those, a new interface would be needed.
>
> I consider _res.options an obsolescent interface, but this change would
> encourage NSS modules to examine it, potentially having to call res_init
> first.  Parsing /etc/gai.conf would be getaddrinfo's responsibility.
>
> I understand that replacing gethostbyname4 is a major undertaking
> (because it would make sense to get rid of the ERANGE protocol at the
> same time).
>
> Thanks,
> Florian

I think desired improvement would be ability to have some context 
between resolutions. Something like res_nquery struct res_state, but for 
protocol independent resolution. It would allow for example pipelining 
of multiple queries on single stream connection. That is not possible at 
the moment AFAIK. But that would be much bigger feature than just 
gethostbyname4 parameters modification. Current API does not allow to 
autodetect support for things like ends0 or similar things, because it 
has not place to store extensions discovered in last response. That is 
great for simple applications, but limiting others.

Cheers,
Petr

-- 
Petr Menšík
Senior Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251016/9604925b/attachment.htm>