Is DNSSEC useful?

DNSSEC validate and authenticate zone data with the purposeto make sure that whatever DNS results, those are genuine.

1. Even if a DNS resolver validates that an authoritative nameserver has send the right data untampered, how do we prevent the DNS resolver from sending tampered DNS response to the DNS client?

2. If the DNS resolver does not support DNSSEC, can it still send DNS queries to an authoritative nameserver that has DNSSEC enabled for its zone?

Thank you

is DNSSEC useful?

This can't be answered (for whatever word you put instead of "DNSSEC" in that sentence) until you start describing against what you want to defend.

When you have the list of risks/vulnerabilities/threats against which you want to defend yourself then you can find out which solutions exist and determine for each solution how much it is useful or not.

DNSSEC is useful against some sort of DNS problems but not on all of them. It introduces itself new problems (ongoing maintenance of signatures and keys for one) but also new features (aggressive caching of everything below a NXDOMAIN if properly validated by DNSSEC).

Even if a DNS resolver validates that an authoritative nameserver has send the right data untampered - how do we prevent the DNS resolver from sending tampered DNS response to the DNS client ?

This is nothing different from today: if you use any public DNS resolver (8.8.8.8, 1.1.1.1, 9.9.9.9 to name a few), you are of course COMPLETELY at the risk of it sending you garbage data. That is a tradeoff. DoH/DoT does not solve anything here because it will protect only the content transmission between you and this resolver, not the content itself. Which content is "protected" by DNSSEC as long as the domain name for which you are doing queries is DNSSEC protected (which is one part you forget in your questions and which make in fact DNSSEC difficult: domain name owner have to enable it AND DNS resolvers have to use the new signatures and do the validation; if one part of this 2 variables equation is not there, DNSSEC is not useful because it just can't work)

So the question revolves more around: which recursive nameserver to use, and where should it run. Of course, for maximum control, you want the resolver to run on YOUR machines. It can still use external resources and DNS resolvers there, but the final DNSSEC validation should happen on your nameserver, not others. Of course this is more work than just relying on any other resource that do all the DNSSEC stuff "for free" for you.

if the DNS resolver does not support DNSSEC, can it still send DNS queries to an authoritative nameserver that has DNSSEC setup for its zone ?

Yes. A resolver wanting to have DNSSEC data has to switch the "DO" flag in its request.

From dig documentation:

        +[no]dnssec
         This option requests that DNSSEC records be sent by setting the DNSSEC OK (DO) bit in the OPT record in the additional section of the query.

Which you can see that way:

$ dig +dnssec example.com

; <<>> DiG 9.16.18 <<>> +dnssec example.com
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40492
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
                           ^^

Or from §3.2.1 of RFC 4035:

3.2.1. The DO Bit

The resolver side of a security-aware recursive name server MUST set the DO bit when sending requests, regardless of the state of the DO bit in the initiating request received by the name server side. If the DO bit in an initiating query is not set, the name server side MUST strip any authenticating DNSSEC RRs from the response but MUST NOT strip any DNSSEC RR types that the initiating query explicitly requested.

If the DNS client (recursive resolver) does this AND if the authoritative nameserver being queried has DNSSEC enabled (hence RRSIG/NSEC/NSEC3 record types in the zones), then the resolver will get those records and then can do the DNSSEC validation.

When you (a DNS stub/client not being a resolver) query a recursive resolver, you have the option of using the CD flag, defined as such:

        +[no]cdflag
        This option sets [or does not set] the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses.

(beware of the possible double negation).

If the client does not use CD, then DNSSEC validation is NOT disabled, hence it is enabled and the remove server will either serve the final answer (if DNSSEC is enabled for the record AND the validation was a success) or will reply with NXDOMAIN if the DNSSEC validation failed. The flag AD will be set to denote that all records were validated as secure, if it is the case (if the query comes from a recursive nameserver, that flag can't exist from an authoritative one as you need the full DNSSEC chain from IANA root to validate any given record)

1. Ideally you validate locally on the client (not all that common today but far from unheard of), or otherwise rely on a secure network path that can bridge the gap from the client to a trusted validating resolver.
   This secure network path could mean something like DNS-over-TLS, DNS-over-HTTPS, DNSCrypt or to some extent a local network (weaker level of trust, but still useful for a subset of attack scenarios).
2. Yes