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 13:49:43 +0200
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 <curl-library_at_lists.haxx.se>:
>
>
>
>> 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.html
Date: Fri, 17 Apr 2026 13:49:43 +0200
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 <curl-library_at_lists.haxx.se>:
>
>
>
>> 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.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-04-17