Re: Using/validating DANE certs?

Timothe Litt via curl-library <[email protected]> Mon, 8 Sep 2025 12:00:04 -0400
Newsgroups	gmane.comp.web.curl.library
Message-ID	<[email protected]>
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.

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.
>

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
OpenPGP_signature.asc (application/pgp-signature, 495 B)