On the Quad9 website:
>Since Quad9 already performs DNSSEC validation, DNSSEC being enabled in the forwarder will cause a duplication of the DNSSEC process, significantly reducing performance and potentially causing false BOGUS responses.
This sounds dodgy. Surely that means Quad9 can poison my DNS?
Not if Quad9 is using DNSSEC, no.
What's the specific threat you're envisioning? If it involves Quad9 themselves being malicious, what would DNSSEC on the forwarding prevent?
This page explains how all of this works in detail: https://quad9.net/news/blog/quad9-enables-dnssec-on-all-serv...
Technically yes, in practice the odds your local resolver is validating DNSSEC is slim (and if you're intentionally configured it to do so, switch to a provider that isn't Quad9).
I use Clouldflare DoT and enabled validation in systemd-resolved some time ago. Not because I would be particularly paranoid, but more out of curiosity how it works. I noticed no problems, except for with Atlassian. They use 2 second level domains (at least), one under .com signed and one under .net (unsigned) (IIRC). Most things worked like normal, but some Jira extension stopped working. Turned out that systemd did reject their signed subdomains. Could not figure out whether the rejection was justified or not. When I asked Claude 7 times about it, I also got 7 contradicting answers... Reported to Atlassian support that their signing is incorrect (some delegation missing). To my surprise they replied: Are you using systemd? And gave a bug number that systemd handles validation wrong in their case.
Haven't had time to study the bug and really understand the whole issue myself. Just left it there with the takeaway that local validation is currently not for non-experts.
(Sorry not at my computer. Details rather vague from memory.)