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: Mon, 8 Sep 2025 18:11:46 +0200
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 :)
Date: Mon, 8 Sep 2025 18:11:46 +0200
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.htmlReceived on 2025-09-08