Comment by tptacek
7 hours ago
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.
DNSSEC and DoH provide different security services. But to get the benefit of DNSSEC, you need to resolve recursively. DoH works for stub resolvers. That's all I'm saying.