Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Question about upcoming "asyn-ares: connect async" change in 8.20
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 17 Apr 2026 09:06:27 +0200
> Am 16.04.2026 um 21:40 schrieb Dmitry Karpov <dkarpov_at_roku.com>:
>
> 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 <stefan_at_eissing.org>
> Sent: Wednesday, April 15, 2026 11:50 PM
> To: libcurl development <curl-library_at_lists.haxx.se>
> Cc: Dmitry Karpov <dkarpov_at_roku.com>
> 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 <curl-library_at_lists.haxx.se>:
>>
>> 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
>
Date: Fri, 17 Apr 2026 09:06:27 +0200
> Am 16.04.2026 um 21:40 schrieb Dmitry Karpov <dkarpov_at_roku.com>:
>
> 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 <stefan_at_eissing.org>
> Sent: Wednesday, April 15, 2026 11:50 PM
> To: libcurl development <curl-library_at_lists.haxx.se>
> Cc: Dmitry Karpov <dkarpov_at_roku.com>
> 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 <curl-library_at_lists.haxx.se>:
>>
>> 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.htmlReceived on 2026-04-17