public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "pemensik at redhat dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug network/30544] New: [RFE] Make getaddrinfo() with hints ai_flags==AF_UNSPEC query only AF present on the system Date: Mon, 12 Jun 2023 14:51:13 +0000 [thread overview] Message-ID: <bug-30544-131@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2023-06-12 14:51 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-06-12 14:51 pemensik at redhat dot com [this message] 2023-06-12 14:58 ` [Bug network/30544] " pemensik at redhat dot com 2023-07-03 11:13 ` pemensik at redhat dot com 2023-07-04 16:14 ` pemensik at redhat dot com 2023-07-04 16:16 ` pemensik at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-30544-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).