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: HTTPS-RR and ECH
- 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, 31 Jul 2026 12:30:10 +0200
> Am 31.07.2026 um 11:31 schrieb Ali Mohammad Pur via curl-library <curl-library_at_lists.haxx.se>:
>
> Am 30.07.26 um 23:12 schrieb Daniel Stenberg:
>
>> We decided to use c-ares for HTTPS (when done without DoH) simply because
>>
>> A) we already optionally use it for asynch name resolves so for some users its not a new dependency
>>
>> B) I'm a c-ares (co-)maintainer since twenty years. I know and trust c-ares.
>>
>> C) No one has stepped up and offered alternative implementations
>
> Surprising as it was to me, it seems c-ares *does* support parsing TLSA records, so I'm perfectly happy to work with c-ares.
>
>> When implementing support for HTTPS the focus was on that record alone and how that would integrate with libcurl and its existing archticture.
>
> tbf I have no real issues with using c-ares as the library doing the resolution, I was referring to the code path that takes the wirefmt and does surgery to extract the https-rr fields specifically - which currently seems limited to the DoH path that I don't really care about.
>
>> I have no personal plans to implement DNSSEC or DANE anytime soon so complicating the implementation for such considerations were not on the map.
>
> I don't think curl should bother with dnssec either, the ideal architecture (at least for my case) would be curl using an upstream stub that does the resolution.
>
>
> I suppose everything seems in place, I'll probably give DANE support another go soon-ish.
If you think about adding things to curl's resolver code, I just opened a discussion at https://github.com/curl/curl/discussions/22452
about how I'd like to restructure the code. This should also help adding new feature more easily.
- Stefan
>
> --
> Cheers,
> ~ Ali Mohammad Pur
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
Date: Fri, 31 Jul 2026 12:30:10 +0200
> Am 31.07.2026 um 11:31 schrieb Ali Mohammad Pur via curl-library <curl-library_at_lists.haxx.se>:
>
> Am 30.07.26 um 23:12 schrieb Daniel Stenberg:
>
>> We decided to use c-ares for HTTPS (when done without DoH) simply because
>>
>> A) we already optionally use it for asynch name resolves so for some users its not a new dependency
>>
>> B) I'm a c-ares (co-)maintainer since twenty years. I know and trust c-ares.
>>
>> C) No one has stepped up and offered alternative implementations
>
> Surprising as it was to me, it seems c-ares *does* support parsing TLSA records, so I'm perfectly happy to work with c-ares.
>
>> When implementing support for HTTPS the focus was on that record alone and how that would integrate with libcurl and its existing archticture.
>
> tbf I have no real issues with using c-ares as the library doing the resolution, I was referring to the code path that takes the wirefmt and does surgery to extract the https-rr fields specifically - which currently seems limited to the DoH path that I don't really care about.
>
>> I have no personal plans to implement DNSSEC or DANE anytime soon so complicating the implementation for such considerations were not on the map.
>
> I don't think curl should bother with dnssec either, the ideal architecture (at least for my case) would be curl using an upstream stub that does the resolution.
>
>
> I suppose everything seems in place, I'll probably give DANE support another go soon-ish.
If you think about adding things to curl's resolver code, I just opened a discussion at https://github.com/curl/curl/discussions/22452
about how I'd like to restructure the code. This should also help adding new feature more easily.
- Stefan
>
> --
> Cheers,
> ~ Ali Mohammad Pur
>
> --
> 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-07-31