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: Using/validating DANE certs?
- 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: Tue, 02 Sep 2025 19:08:12 +0200
> Are there actual web sites on the internet deployed with CA certs in DNS beyond just singular experiments?
I know of a couple deployments that aren't test pages, at least <torproject.org> still has DANE-EE set up. Though I'd imagine most such deployments would be internal as there's no real browser that supports it (yet!).
There was also some interest in having that work through a proxy[1], not sure if that's still being worked on actively.
> Won't that immediately discard a rather sizable portion of users? I would guess that a majority of users don't run one on the machine they invoke curl on.
Not sure if it would, though my main interest in using this through a browser that already does dnssec validation is likely a large source of bias.
> How would curl figure out that it works with a resolver that verifies DNSSEC?
My suggestion was to assume so and not think about it except in cases where curl is doing the resolution manually.
IIRC Niall called it a "hand of God" approach to getting the records :P
> How is that different from just providing a CACERT bundle in a dedicated file?
That would only be possible with DANE-TA, also the PKIX-* modes would require both DANE and CA validation to accept the connection.
> we should [not] build functionality on the plain assumption that users will use trusted resolvers with working DNSSEC validation.
I'm not certain either way, we already work on many assumptions on DNS.
Still, I wouldn't put the number of people running local stubs with dnssec validation enabled so low, systemd-resolved supports dnssec and it seems to be enabled on my system without me explicitly enabling it (n=3, so probably needs more investigation).
> rather flaky functionality that will break or not break fairly arbitrarily
You mean I'm not supposed to offer sacrifices to the DNS gods before my tooling starts working?
Fair point, though I'm not sure if it's any more of an arbitrary breakage than having a v6-only resolver on a v4-only network produces...
> I don't understand how "generic RR support" helps curl users work with DANE, and I don't think MX is a record curl needs to care about.
Perhaps not, though there are things that curl may want to care about (ECH, HTTPS RR, and TLSA for DANE).
An alternative I can think of to the CURLOPT approach is to fully embrace the idea of a (configurable) upstream resolver, drop every ad-hoc/libc-based lookups and ask that upstream...though this admittedly has quite a large scope.
[1]: <https://github.com/buffrr/letsdane>
Am 2. September 2025 18:02:07 MESZ schrieb Daniel Stenberg <daniel_at_haxx.se>:
>On Mon, 1 Sep 2025, Ali Mohammad Pur wrote:
>
>> Nothing particularly concrete, but I've heard a bunch about wanting to forego "normal" CA certs for DANE-EE. Re browsers, I know of at least one extension that tries to verify DANE[1].
>
>Are there actual web sites on the internet deployed with CA certs in DNS beyond just singular experiments?
>
>DANE seems mostly implemented for SMTP where I'm looking.
>
>>> getting the DNSSEC stuff done correctly with the all the keys etc to verify that the records we get are legitimate for the domain.
>>
>> Yeah I'm personally proposing that curl shouldn't concern itself with this, asking the user to use a resolver that verifies DNSSEC is fairly reasonable to me.
>
>Won't that immediately discard a rather sizable portion of users? I would guess that a majority of users don't run one on the machine they invoke curl on. How would curl figure out that it works with a resolver that verifies DNSSEC?
>
>> if we go the route of my proof-of-concept, the user would have to provide the TLSA/DANE records (wirefmt base64'd) via some CURLOPT[2];
>
>How is that different from just providing a CACERT bundle in a dedicated file?
>
>> a nicer extension could have libcurl do the resolution itself if requested, trusting the underlying resolver for DNSSEC validation.
>
>I don't think we should build functionality on the plain assumption that users will use trusted resolvers with working DNSSEC validation. Especially as I suspect that's a minority of users.
>
>It also makes it a rather flaky functionality that will break or not break fairly arbitrarily in the eyes of the user, depending on how the local resolver works or doesn't work.
>
>> Alternatively I can see an API that would take the records as parsed fields, but I think it's worth having more "generic" RR support - I know at least MX is/was being discussed at some point.
>
>I don't understand how "generic RR support" helps curl users work with DANE, and I don't think MX is a record curl needs to care about.
>
>--
>
> / daniel.haxx.se || https://rock-solid.curl.dev
Date: Tue, 02 Sep 2025 19:08:12 +0200
> Are there actual web sites on the internet deployed with CA certs in DNS beyond just singular experiments?
I know of a couple deployments that aren't test pages, at least <torproject.org> still has DANE-EE set up. Though I'd imagine most such deployments would be internal as there's no real browser that supports it (yet!).
There was also some interest in having that work through a proxy[1], not sure if that's still being worked on actively.
> Won't that immediately discard a rather sizable portion of users? I would guess that a majority of users don't run one on the machine they invoke curl on.
Not sure if it would, though my main interest in using this through a browser that already does dnssec validation is likely a large source of bias.
> How would curl figure out that it works with a resolver that verifies DNSSEC?
My suggestion was to assume so and not think about it except in cases where curl is doing the resolution manually.
IIRC Niall called it a "hand of God" approach to getting the records :P
> How is that different from just providing a CACERT bundle in a dedicated file?
That would only be possible with DANE-TA, also the PKIX-* modes would require both DANE and CA validation to accept the connection.
> we should [not] build functionality on the plain assumption that users will use trusted resolvers with working DNSSEC validation.
I'm not certain either way, we already work on many assumptions on DNS.
Still, I wouldn't put the number of people running local stubs with dnssec validation enabled so low, systemd-resolved supports dnssec and it seems to be enabled on my system without me explicitly enabling it (n=3, so probably needs more investigation).
> rather flaky functionality that will break or not break fairly arbitrarily
You mean I'm not supposed to offer sacrifices to the DNS gods before my tooling starts working?
Fair point, though I'm not sure if it's any more of an arbitrary breakage than having a v6-only resolver on a v4-only network produces...
> I don't understand how "generic RR support" helps curl users work with DANE, and I don't think MX is a record curl needs to care about.
Perhaps not, though there are things that curl may want to care about (ECH, HTTPS RR, and TLSA for DANE).
An alternative I can think of to the CURLOPT approach is to fully embrace the idea of a (configurable) upstream resolver, drop every ad-hoc/libc-based lookups and ask that upstream...though this admittedly has quite a large scope.
[1]: <https://github.com/buffrr/letsdane>
Am 2. September 2025 18:02:07 MESZ schrieb Daniel Stenberg <daniel_at_haxx.se>:
>On Mon, 1 Sep 2025, Ali Mohammad Pur wrote:
>
>> Nothing particularly concrete, but I've heard a bunch about wanting to forego "normal" CA certs for DANE-EE. Re browsers, I know of at least one extension that tries to verify DANE[1].
>
>Are there actual web sites on the internet deployed with CA certs in DNS beyond just singular experiments?
>
>DANE seems mostly implemented for SMTP where I'm looking.
>
>>> getting the DNSSEC stuff done correctly with the all the keys etc to verify that the records we get are legitimate for the domain.
>>
>> Yeah I'm personally proposing that curl shouldn't concern itself with this, asking the user to use a resolver that verifies DNSSEC is fairly reasonable to me.
>
>Won't that immediately discard a rather sizable portion of users? I would guess that a majority of users don't run one on the machine they invoke curl on. How would curl figure out that it works with a resolver that verifies DNSSEC?
>
>> if we go the route of my proof-of-concept, the user would have to provide the TLSA/DANE records (wirefmt base64'd) via some CURLOPT[2];
>
>How is that different from just providing a CACERT bundle in a dedicated file?
>
>> a nicer extension could have libcurl do the resolution itself if requested, trusting the underlying resolver for DNSSEC validation.
>
>I don't think we should build functionality on the plain assumption that users will use trusted resolvers with working DNSSEC validation. Especially as I suspect that's a minority of users.
>
>It also makes it a rather flaky functionality that will break or not break fairly arbitrarily in the eyes of the user, depending on how the local resolver works or doesn't work.
>
>> Alternatively I can see an API that would take the records as parsed fields, but I think it's worth having more "generic" RR support - I know at least MX is/was being discussed at some point.
>
>I don't understand how "generic RR support" helps curl users work with DANE, and I don't think MX is a record curl needs to care about.
>
>--
>
> / daniel.haxx.se || https://rock-solid.curl.dev
-- Cheers, ~Ali Mohammad Pur
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-09-02