> 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 <[email protected]>:
>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.html
