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
