[Bug network/30544] New: [RFE] Make getaddrinfo() with hints ai_flags==AF_UNSPEC query only AF present on the system

[Bug network/30544] New: [RFE] Make getaddrinfo() with hints ai_flags==AF_UNSPEC query only AF present on the system

[pemensik at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30544

            Bug ID: 30544
           Summary: [RFE] Make getaddrinfo() with hints
                    ai_flags==AF_UNSPEC query only AF present on the
                    system
           Product: glibc
           Version: 2.39
               URL: https://bugzilla.redhat.com/show_bug.cgi?id=2182745
            Status: NEW
          Severity: normal
          Priority: P2
         Component: network
          Assignee: unassigned at sourceware dot org
          Reporter: pemensik at redhat dot com
  Target Milestone: ---

Description of problem:
There are still quite many networks offering just single address family
connectivity. Quite a lot networks are still IPv4 only. They do not offer IPv6
route, they do not offer IPv6 addresses. What sense does it make on such
networks to request AAAA queries from dns NSS plugin? Unless the application
wants IPv6 explicitly, use just families with working connectivity. Application
without AI_PASSIVE flag is very likely to call connect(2). Which will try first
IPv6 addresses for the hostname. When a IPv6 route is missing they fail
immediately. And they always have to fail, that is known before it is started.


Version-Release number of selected component (if applicable):
glibc-2.37.9000-4.fc39.x86_64

How reproducible:
reliable

Steps to Reproduce:
1. have just IPv4 connectivity. ip -6 route reports just localhost and
link-local networks
2. getent ahosts example.org
3.

Actual results:
# getent ahosts example.org
93.184.216.34   STREAM example.org
93.184.216.34   DGRAM  
93.184.216.34   RAW    
2606:2800:220:1:248:1893:25c8:1946 STREAM 
2606:2800:220:1:248:1893:25c8:1946 DGRAM  
2606:2800:220:1:248:1893:25c8:1946 RAW 

Expected results:
# getent ahosts example.org
93.184.216.34   STREAM example.org
93.184.216.34   DGRAM  
93.184.216.34   RAW  

Additional info:
To keep backward compatibility and forward compatibility at the same time, I
propose to add two new options into /etc/resolv.conf. ipv4 option would be set
when IPv4 connectivity is present. ipv6 option would be set when IPv6 route
exists. which is not localhost and not link-local address. There are modules
capable of doing something interesting even if the network itself does not
provide IPv6 connectivity. files NSS module should work in any case. mdns NSS
plugin provided by nss-mdns could work even with just link-local addresses in
and an usable way. But dns protocol does not include scope_id required for
link-local addresses. That makes them unusable in form of hostnames.

If both options ipv4 ipv6 were used or none of them would be present, the
behaviour should be unchanged from now. This change would make AF_UNSPEC to
query only addresses usable at the moment. Unlike AI_ADDRCONFIG it would not
spend extra cycles before each connection, but would rely on external service
to watch changing connectivity.

It is already common that /etc/resolv.conf is maintained by external service.
Be it Network Manager or systemd-resolved, they are as a daemon better suited
to monitor connectivity and inform applications by changing options as soon as
it changes. This change would help both legacy IPv4 only network and future
IPv6 only networks as well. If the network does not provide IPv4 connectivity
at all, common application does not need A queries anyway. It is likely some
IPv6 translation is being done for legacy connectivity on such networks.

I started thinking about why end systems are doing unnecessary AAAA queries,
which in turn people try to block on local DNS caches. This is just ridiculous
circle.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/30544] [RFE] Make getaddrinfo() with hints ai_flags==AF_UNSPEC query only AF present on the system

[pemensik at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30544

Petr Menšík <pemensik at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |19697


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=19697
[Bug 19697] /etc/gai.conf option to configure AF_UNSPEC lookups
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/30544] [RFE] Make getaddrinfo() with hints ai_flags==AF_UNSPEC query only AF present on the system

[pemensik at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30544

--- Comment #1 from Petr Menšík <pemensik at redhat dot com> ---
Created some changes for a test:
https://github.com/InfrastructureServices/glibc/tree/gai-ipv4-ipv6

But it seems to me instead of gaih_getanswer_noaaaa answer, it should use just
_nss_dns_gethostbyname3_r with proper AF. That is when only one of flags is
used.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/30544] [RFE] Make getaddrinfo() with hints ai_flags==AF_UNSPEC query only AF present on the system

[pemensik at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30544

--- Comment #2 from Petr Menšík <pemensik at redhat dot com> ---
Created test build with modified Fedora Rawhide branch.

On first glance, it behaves correctly.

Works:

- getent ahosts fedoraproject.org
- getent ahostsv4 fedoraproject.org
- getent ahostsv6 fedoraproject.org

As expected it offers only single address with "options edns0 ipv4" to ahosts.
But what were unexpected is reaction to ping.

# grep options /etc/resolv.conf 
options edns0 ipv4
# ping -6 fedoraproject.org
ping: fedoraproject.org: Address family for hostname not supported

# after modification
# grep options /etc/resolv.conf 
options edns0
# ping -c 1 -6 fedoraproject.org
PING fedoraproject.org(2620:52:3:1:dead:beef:cafe:fed7
(2620:52:3:1:dead:beef:cafe:fed7)) 56 data bytes
# ping -c 1 -4 fedoraproject.org
PING  (38.145.60.21) 56(84) bytes of data.

It seems some unwanted remains of no-aaaa option are present. A bit different
approach should be chosed to avoid that. But close enough.

Question is how tests should be modified. I am not very confident in
implementing that. This requires responses from dns, not sure how to fake them
properly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/30544] [RFE] Make getaddrinfo() with hints ai_flags==AF_UNSPEC query only AF present on the system

[pemensik at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30544

Petr Menšík <pemensik at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pemensik at redhat dot com

--- Comment #3 from Petr Menšík <pemensik at redhat dot com> ---
Created attachment 14954
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14954&action=edit
First-candidate option ipv46

Candidate patch used to test proposed change.

-- 
You are receiving this mail because:
You are on the CC list for the bug.