Re: HTTPS-RR and ECH

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.html