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.
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.)
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.
Read rfc3655 for the details. 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 09:58, Daniel Stenberg via curl-library wrote:
On Sun, 7 Sep 2025, Ali Mohammad Pur wrote:we can trust the resolver, or do our own DNSSEC validation locally - no other possible way.If we cannot verify the resolver somehow, then we cannot trust it but we must validate the data ourselves before we rely on information from DNS that cannot be verified also using other means. Othwerwise we risk leaving users vulnerable.If a user doesn't trust their resolver, maybe they should not be using it? I do understand that my suggestion expands the trust base, however.That's why TLS and the CA system is built *on-top* of it. If the DNS brings back the wrong info, the certficate check fails and we get no data. We don't need to trust the resolver for this.I claim that most users (in the most large-scale sense possible of users) don't run a DNSSEC secured local resolver so untrusted DNS data is the default.That's reasonable, I'd be in favour of verifying DNSSEC locally for all cases even (sadly not very viable though, a big chunk of the open web would fail validation).Then we're in agreement!How can we do validation locally? How do we get the keys necessary to verify the data? That seems to be the part that makes this complicated.
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
