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: Timothe Litt <litt_at_acm.org>
Date: Mon, 8 Sep 2025 12:39:34 -0400
> I agree, though assumption seems to be that a significant set of users
> do not have stubs that do DNSSEC validation, see earlier in the thread:
If you trust your stub resolver not to set AD (and only a malicious one
would), then the DANE code can simply refuse to validate.
If you want DANE, you use either a trustworthy validating resolver over
a secure channel, or a stub that uses one (and passes AD along from the
resolver that it trusts).
Otherwise, it doesn't work. And curl has no obligation to work-around
such a configuration error, although a suitable error message could be
generated: "Connection failed - DNSSEC validation failed or not
offered") Implementing DNSSEC validation in an application is
discouraged in 3655.
It's analogous to implementing TCP over UDP in the application because
you don't trust the kernel's TCP stack...
(But let's not talk about HTTP/3...)
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 08-Sep-25 12:11, Ali Mohammad Pur via curl-library wrote:
> Am 08.09.25 um 18:00 schrieb Timothe Litt via curl-library:
>
>> The AD bit in a response indicates that the data has been validated,
>> if DO was set in the requres. (rfc3655)
>>
>> In theory, DOT (DNS over TCP) or DOH (DNS over HTTPS) can be used to
>> ensure that you're talking to a resolver that you trust. The usual
>> TLS trust chain caveats apply.
>>
> Right, my interpretation of Daniel's question was that we do not want
> to trust the resolver at all, so DO would be completely meaningless.
>>
>> Or in the usual (and expected design case), if you use a resolver
>> that supports DNSSEC over another trusted channel e.g. (localhost:53,
>> unix domain socket), you can trust the AD bit. A resolver that does
>> not support DNSSEC should never set AD. A resolver that does support
>> DNSSEC sets AD IFF it has validated all records in the response (or
>> otherwise ensured that the data meets the local security policy.)
>>
> I agree, though assumption seems to be that a significant set of users
> do not have stubs that do DNSSEC validation, see earlier in the thread:
>
> > 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.
>
>> If you use a resolver over an untrustworthly channel, or configure a
>> (malicious or misconfigured) resolver that lies, all bets are off.
>>
>> Doing your own DNSSEC validation is non-trivial; maintaining it is
>> non-trivial; it's not recommended.
>>
> Nice, now I get to not say that :)
>
> --
> Cheers,
> ~ Ali Mohammad Pur
>
Received on 2025-09-08
Date: Mon, 8 Sep 2025 12:39:34 -0400
> I agree, though assumption seems to be that a significant set of users
> do not have stubs that do DNSSEC validation, see earlier in the thread:
If you trust your stub resolver not to set AD (and only a malicious one
would), then the DANE code can simply refuse to validate.
If you want DANE, you use either a trustworthy validating resolver over
a secure channel, or a stub that uses one (and passes AD along from the
resolver that it trusts).
Otherwise, it doesn't work. And curl has no obligation to work-around
such a configuration error, although a suitable error message could be
generated: "Connection failed - DNSSEC validation failed or not
offered") Implementing DNSSEC validation in an application is
discouraged in 3655.
It's analogous to implementing TCP over UDP in the application because
you don't trust the kernel's TCP stack...
(But let's not talk about HTTP/3...)
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 08-Sep-25 12:11, Ali Mohammad Pur via curl-library wrote:
> Am 08.09.25 um 18:00 schrieb Timothe Litt via curl-library:
>
>> The AD bit in a response indicates that the data has been validated,
>> if DO was set in the requres. (rfc3655)
>>
>> In theory, DOT (DNS over TCP) or DOH (DNS over HTTPS) can be used to
>> ensure that you're talking to a resolver that you trust. The usual
>> TLS trust chain caveats apply.
>>
> Right, my interpretation of Daniel's question was that we do not want
> to trust the resolver at all, so DO would be completely meaningless.
>>
>> Or in the usual (and expected design case), if you use a resolver
>> that supports DNSSEC over another trusted channel e.g. (localhost:53,
>> unix domain socket), you can trust the AD bit. A resolver that does
>> not support DNSSEC should never set AD. A resolver that does support
>> DNSSEC sets AD IFF it has validated all records in the response (or
>> otherwise ensured that the data meets the local security policy.)
>>
> I agree, though assumption seems to be that a significant set of users
> do not have stubs that do DNSSEC validation, see earlier in the thread:
>
> > 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.
>
>> If you use a resolver over an untrustworthly channel, or configure a
>> (malicious or misconfigured) resolver that lies, all bets are off.
>>
>> Doing your own DNSSEC validation is non-trivial; maintaining it is
>> non-trivial; it's not recommended.
>>
> Nice, now I get to not say that :)
>
> --
> Cheers,
> ~ Ali Mohammad Pur
>
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature