Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Using/validating DANE certs?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Mon, 8 Sep 2025 12:00:04 -0400
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.
>
Received on 2025-09-08
Date: Mon, 8 Sep 2025 12:00:04 -0400
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
- application/pgp-signature attachment: OpenPGP digital signature