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: Ali Mohammad Pur via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 31 Jul 2026 11:31:36 +0200
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.
Date: Fri, 31 Jul 2026 11:31:36 +0200
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.
-- Cheers, ~ Ali Mohammad Pur -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-07-31