Re: HTTPS-RR and ECH

> Am 31.07.2026 um 11:31 schrieb Ali Mohammad Pur via curl-library <[email protected]>:
> 
> 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.html