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)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.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.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: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.)> 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
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
