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: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 30 Jul 2026 23:12:25 +0200 (CEST)
On Thu, 30 Jul 2026, Ali Mohammad Pur via curl-library wrote:
> I'd like to yet again advocate for a more generic DNS client so we can
> eventually implement DANE/TLSA - I've poked the lists about this before and
> I think the biggest issue was that we'd need a whole DNS client for it; sure
> would be convenient if HTTPS-RR gave us a real client instead of one hyper
> focused on getting HTTPS RRs.
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
When implementing support for HTTPS the focus was on that record alone and how
that would integrate with libcurl and its existing archticture. I have no
personal plans to implement DNSSEC or DANE anytime soon so complicating the
implementation for such considerations were not on the map.
But yes, if DNSSEC and DANE should be supported, that's a lot of work and it
would require using another library.
Date: Thu, 30 Jul 2026 23:12:25 +0200 (CEST)
On Thu, 30 Jul 2026, Ali Mohammad Pur via curl-library wrote:
> I'd like to yet again advocate for a more generic DNS client so we can
> eventually implement DANE/TLSA - I've poked the lists about this before and
> I think the biggest issue was that we'd need a whole DNS client for it; sure
> would be convenient if HTTPS-RR gave us a real client instead of one hyper
> focused on getting HTTPS RRs.
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
When implementing support for HTTPS the focus was on that record alone and how
that would integrate with libcurl and its existing archticture. I have no
personal plans to implement DNSSEC or DANE anytime soon so complicating the
implementation for such considerations were not on the map.
But yes, if DNSSEC and DANE should be supported, that's a lot of work and it
would require using another library.
-- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-07-30