DNSSEC validation on your forwarder would prevent a maliciously modified record from Quad9 (or others) from being accepted locally - i.e. "Quad9 can poison my DNS".
I've always been of two minds on this. On one hand, that concern is beyond any reasonable level of security/performance/reliability tradeoff for most any user. At the same time, it is a bit of a shame DNS doesn't have a more scalable & performant approach to security which can just always be done without having to consider it a tradeoff, however minor in practice.
You are rely here on the assumption what your resolver already knows what the zone is DNSSEC signed. If your forwarder or resolver strips that information?..
1. The forwarder gets a response claiming the record is supposed to be DNNSEC signed from the parent (recursively traversing from the root). The forwarder checks the signature of this claim. If the signature is valid, the forwarder continues on to validate the signature of the record and checks its validity to know if the info was secure. If the signature is invalid, the forwarder knows any information any information is not able to be validated as secure
- Somewhere during the recursive checks through the root, the forwarder gets an unsigned (no DNSSEC) or invalidly signed (e.g. your stripped response) response. The forwarder knows any information is not able to be validated as secure.
- A claim for lack of configuration or support of DNSSEC records comes back. The forwarder knows any information is not able to be validated as secure.
So you always know whether or not the information was secure, it's just if it was insecure you don't know if it's because it was just never secured or if someone tried to tamper with it. And that should make sense, an insecure message is by definition one which you can't tell if it has been tampered with.
You have two recursers (or recurser-capable systems, in the case of a forwarder), an upstream that you tentatively trust and a downstream one you trust completely (because end systems use stub resolvers and have to blindly trust a recursive resolver somewhere).
Can you be more specific about how, using current DNS software, that downstream resolver can reliably detect whether a zone is DNSSEC signed? The upstream recurser can erase every DNSSEC record in the tree if it wants. What does the downstream recurser do short of jettisoning the upstream and doing all its own recursive lookups?
Your other comment was [dead] before I could get to it for some odd reason so I'm going to reply here again since I know you're not a bot or anything :).
Perhaps the confusion comes from the context of the above being "what Quad9 says to do to your forwarder's DNSSEC configuration" and it'd be easier to ask this question with a fully fresh situation & context?
I can sense the doubt in the questions but I assure you what I'm discussing is just the defaults behavior of most DNS server software. E.g., I'll walk through below with BIND's default behavior when configured with recursion and a forwarder entry. The downstream forwarder (our BIND server) asks for all of the relevant DNSSEC records for the query to "example.com." from the root on down the FQDN. The upstream responds with a set of record responses. One of 3 things happens:
1) The signature chain checks out all the way to the root, who's key info comes from a file included the DNS software rather than a DNSSEC query. The integrity of the end record is trusted (not the upstream itself) and the process is complete.
2) The signature chain checks out but part way down it (explicitly) ends early. E.g. "example" is not configured for DNSSEC but "com" and "." are so .com ends the signature chain with a signed "example will not be signed" handoff. The process is complete, the record is securely known to be insecurely defined by the authoritative servers for "example" per the signatures from the .com records and the local security anchor (e.g. bind.keys file)
3) The signature chain doesn't validate at some point. This could be because the malicious upstream tried to modify a record or it could be because the malicious upstream tried to fake lack of record response even though it can't fake the parent domain's signature of that (recursively to the root because the root keys are local to the server). In this case, the invalid records from the malicious upstream are jettisoned in favor of trying to get valid responses via recursive resolution.
.
Tying it all back together: Because the downstream forwarder is only looking for the signature chain to trust the record, it just wants to get those records as fast as possible. BIND determines the most likely way to get a quick response is to ask the forwarder. It then checks the full signature of all of these, almost always bind was right - the forwarder had the records needed cached and didn't try to modify them. If the forwarder was malicious or just in error bind throws these away and tries to recurse the answer directly.
Quad9 wants people to disable it because it's extra record requests, most people don't care, and, if you trust Quad9, you can just send your request in a DoH or DoT tunnel to secure the last hop more efficiently while they do the validation of the record itself.
I think we're talking past each other. There's no uncertainty about how DNSSEC works between servers. Any recursive lookup can validate a signature chain.
The question is how DNSSEC breaks down in the last mile, where recursive lookups aren't happening. A stub resolver --- every resolver on an ordinary workstation is a stub resolver --- can absolutely be tricked by its upstream DNS server. Quad9 can lie to clients about whether it validated DNSSEC, or whether DNSSEC was present at all.
I've always been of two minds on this. On one hand, that concern is beyond any reasonable level of security/performance/reliability tradeoff for most any user. At the same time, it is a bit of a shame DNS doesn't have a more scalable & performant approach to security which can just always be done without having to consider it a tradeoff, however minor in practice.