Re: Question about upcoming "asyn-ares: connect async" change in 8.20

Follow up: DNS resolution delay implemented in https://github.com/curl/curl/pull/21354

> Am 17.04.2026 um 09:06 schrieb Stefan Eissing via curl-library <[email protected]>:
> 
> 
> 
>> Am 16.04.2026 um 21:40 schrieb Dmitry Karpov <[email protected]>:
>> 
>> Hi Stefan,
>> 
>> Thanks for explanations! Now, the direction is clearer, but I think one thing is still worth further discussion.
>> 
>> The Happy Eyeballs v3 proposal document mentions the "resolution time delay":
>> 
>>>> 
>> 4.2. Handling DNS Answers Asynchronously
>> ...
>> The client moves onto sorting addresses and establishing connections once one of the following condition sets is met:
>> 
>> Either:
>>   Some positive (non-empty) address answers have been received AND
>>   A positive (non-empty) or negative (empty) answer has been received for the preferred address family that was queried AND
>>   SVCB/HTTPS service information has been received (or has received a negative response)
>> 
>> Or:
>>   Some positive (non-empty) address answers have been received AND
>>   A resolution time delay has passed after which other answers have not been received.
>> ...
>> 
>> The resolution time delay is a short time that provides a chance to receive preferred addresses (via AAAA records) along with service information (via SVCB/HTTPS records). 
>> This accounts for the case where the AAAA or SVCB/HTTPS records follow the A records by a few milliseconds. This delay is referred to as the "Resolution Delay".
>> 
>> The RECOMMENDED value for the Resolution Delay is 50 milliseconds.
> 
> This is an aspect we have not implemented yet. I see your point in regard to AAAA addresses. curl always treated them as the preferred address family. I am hesitant to implement the 50ms delay for HTTPS records right now since they are still rare.
> 
> My next iteration will most likely be:
> - if a AAAA answer has been received (positive or negative), continue connecting.
> - without AAAA answer, wait the 50ms before continuing.
> 
>>>> 
>> 
>> As far as I understand it, the "Resolution Delay" is a waiting period, which directs the client to wait for the preferred family DNS response (IPv6) before trying to
>> make a connection attempt on a not-preferred one (IPv4) in cases when A response came earlier.
>> 
>> If so, then I guess it becomes a new "Happy Eyeballs timeout" value and thus will probably be controlled by CURLOPT_HAPPY_EYEBALLS_TIMEOUT_MS option.
>> Am I right, or the "Happy Eyeballs timeout" will have a different meaning than the "Resolution Delay"?
> 
> The happy eyeball timeout setting has the same semantics as before, spacing the different connect attempts.
> 
>> 
>> I am asking because it is not clear what is the meaning of the "Happy Eyeballs timeout"(HET) with the new approach, as connection attempts now
>> may start immediately upon receiving DNS response and without waiting for HET to expiry.
>> 
>> I have some concerns about it because I have seen network configurations when AAAA responses may come later than A responses, but it was worth waiting
>> because IPv6 connections were still faster, and I am afraid that the new mechanism may favor IPv4 connectivity more than before, unless client is provided a mechanism
>> to tune the "Resolution Delay" and give more slack to IPv6.
>> 
>> Thanks,
>> Dmitry
>> 
>> -----Original Message-----
>> From: Stefan Eissing <[email protected]> 
>> Sent: Wednesday, April 15, 2026 11:50 PM
>> To: libcurl development <[email protected]>
>> Cc: Dmitry Karpov <[email protected]>
>> Subject: [EXTERNAL] Re: Question about upcoming "asyn-ares: connect async" change in 8.20
>> 
>> Hi,
>> 
>>> Am 16.04.2026 um 00:25 schrieb Dmitry Karpov via curl-library <[email protected]>:
>>> 
>>> Hi All,
>>> 
>>> I have a question about the "asyn-ares: connect async" change (https://github.com/curl/curl/pull/21205) in the upcoming 8.20 release.
>>> 
>>> The PR description says:
>>> "This PR updates the async DNS resolver behavior (notably the c-ares backend) to issue separate A and AAAA queries and make partial DNS information available earlier, enabling connection attempts to begin as soon as the first relevant DNS response arrives."
>>> 
>>> I am wondering how this new behavior will affect the Happy Eyeballs for dual-stack?
>>> 
>>> For example, if the A query result is received earlier than the AAAA query one, does it mean that IPv4 connect attempts will start before IPv6 ones?
>> 
>> Yes.
>> 
>>> Or IPv4 will still have to wait in this case until the HEB timeout expires?
>> 
>> No, the intent of splitting the query is to react to the first incoming response.
>> 
>>> Also, it seems that this change makes it possible to go with a slower IPv4 connection if A response comes faster than AAAA response.
>>> 
>>> Before this change, the dual-stack race was just between connections, 
>>> and the fastest would win, but now as DNS replies are also part of the "stack" race, it seems possible that a slower stack connection may win if it's DNS reply comes faster.
>>> 
>>> It would be helpful to get some clarifications how the Happy Eyeballs mechanism will work with this change.
>> 
>> The intent of the changes (and there will be more coming) is to follow the Happy Eyeballs v3 proposal (https://www.ietf.org/archive/id/draft-ietf-happy-happyeyeballs-v3-01.html), at least to an extent that the curl team considers reasonable.
>> 
>> Cheers,
>> Stefan
>> 
>>> 
>>> Thanks,
>>> Dmitry Karpov
>>> 
>>> --
>>> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
>>> Etiquette:   https://curl.se/mail/etiquette.html
>> 
> 
> -- 
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette:   https://curl.se/mail/etiquette.html


-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html