I would like to continue discussing this issue as I must carry on and apply my patch on subsequent libcurl releases. The issue with bad AAAA queries is still present with certain ISPs/routers, and it affects IPv4-only resolution mode without my patch.
So, the intent described in the statement "It is important that *all* addresses versions are resolved, even if not used..." from 84d2839740ca7804 will cause transfer timeouts for IPv4-only resolution mode in case of bad/missing AAAA responses. My patch implementing my proposal below addresses it with a price of one more DNS query (which will be cached) when IPv6-only resolution mode is used later on after IPv4. Thanks, Dmitry Karpov -----Original Message----- From: curl-library <curl-library-boun...@lists.haxx.se> On Behalf Of Dmitry Karpov via curl-library Sent: Monday, May 23, 2022 1:04 PM To: Daniel Stenberg <dan...@haxx.se> Cc: Dmitry Karpov <dkar...@roku.com>; Dmitry Karpov via curl-library <curl-library@lists.haxx.se> Subject: RE: IPv6 resolution problems for IPv4 resolve mode I don't think that my suggestion will fully revert 84d2839740ca7804 as I don't see any problems with connection reuse the way it is now. It will just make a few adjustments to the way how addresses are resolved and cached following the approach that I initially described: 1. Use only IPv4 DNS queries for IPv4-only resolve mode. 2. For the "dual-stack" and IPv6-only resolve modes use "dual-stack" DNS queries. NOTE: I don't suggest to use IPv6-only DNS queries for the IPv6-only resolve mode because IPv6 still has more issues than IPv4, and if some client wants to implement its own "happy-eye-balls" mechanism (when IPv6 is tried first and then switching to IPv4) then "dual-stack" DNS queries will save on resolution time when trying IPv4 after failed IPv6. 3. Clear DNS cache entry if the cached entry doesn't contain address for the requested family and redo DNS query for the host name. This is needed when requests using IPv4-only resolve mode are followed by requests to the same host but using IPv6 mode. My approach addresses the concern and important note in the 84d2839740ca7804: "It is important that all addresses versions are resolved, even if not used in that transfer in particular, because the result is cached, and could be useful for a different transfer with a different CURLOPT_IPRESOLVE setting." I want to emphasize that I suggest to use dual-stack DNS queries for both dual-stack and IPv6-only resolve mode (thus avoiding IPv6 resolve mode to use only IPv6 DNS queries) because of still existing disparity between IPv4 and IPv6 support in the field. The "dual-stack" DNS queries for IPv6 will help to switch quickly to IPv4 connections if IPv6 connection fails in cases when some client application wants to implement its own stack selection mechanism (without spending additional time on IPv4 DNS query when trying IPv4 mode for the same host). I think this logic (IPv4 DNS query for IPv4 resolve, and dual-stack DNS query for the other resolve modes) is simple enough and can be described in one more paragraph in the CURLOPT_IPRESOLVE section. And it covers well basically all major practical use cases when IPv6/dual-stack may be involved. I am attaching a patch file with the changes implementing my suggestion, which resolved the issues I stepped on. Thanks, Dmitry Karpov -----Original Message----- From: Daniel Stenberg <dan...@haxx.se> Sent: Monday, May 23, 2022 4:22 AM To: Dmitry Karpov <dkar...@roku.com> Cc: Dmitry Karpov via curl-library <curl-library@lists.haxx.se> Subject: RE: IPv6 resolution problems for IPv4 resolve mode On Fri, 20 May 2022, Dmitry Karpov wrote: > I understand the rationale for keeping DNS entry in the cache for both > addresses, but in my proposal, I suggest to use "dual-stack" DNS > queries only for dual-stack and IPv6-only modes. This will make > IPv4-only requests in IPv6-enabled libcurl builds behave the same way > as they do in IPv4-only builds. I believe that suggestion would basically revert 84d2839740ca7804, so it would need some careful considerations. Maybe we should rather add some variation to CURLOPT_IPRESOLVE for more explicit *also applies to name resolving*? We might need to do something about caching/connection reuse too, or at least decide and document exactly how those would work in these siutations. -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
