Comment by pbhjpbhj
10 hours ago
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?
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.)
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...
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 reply →
Wait, I must be misunderstanding you, because if you're resolving off Quad9, they can definitely poison your DNSSEC-signed records. Between a stub resolver and a recursor DNSSEC collapses down to a single "yes it was signed" bit in the header.
To protect yourself from an upstream resolver using DNSSEC, you need to be doing something akin to a full recursive lookup yourself. This is a flaw in the DNSSEC design and a reason why DoH took off instead.
I don't know the details but knot-resolver asks for DS records of the domain being looked up when forwarding to avoid needing to do a full recursive lookup to validate DNSSEC. As I recall from what I've read this works almost everywhere, including Quad9, but not Google DNS due to a bug that they claim to have identified three years ago but haven't fixed. But as I understand it this is not how recursive resolvers validate so it is extra data that the forwarding server needs to request and cache.
> To protect yourself from an upstream resolver using DNSSEC, you need to be doing something akin to a full recursive lookup yourself. This is a flaw in the DNSSEC design and a reason why DoH took off instead.
What? I don't see how you can call that a flaw in DNSSEC when DoH is no better in this regard; it doesn't even attempt to protect against a malicious recursive resolver. The only way to do that is to validate DNSSEC on the client.
1 reply →
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).