Re: Using/validating DANE certs?

Timothe Litt via curl-library <[email protected]> Mon, 8 Sep 2025 12:39:34 -0400
Newsgroups	gmane.comp.web.curl.library
Message-ID	<[email protected]>
> 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
OpenPGP_signature.asc (application/pgp-signature, 495 B)