Comment by zamadatix
2 months ago
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?..
At a high level, one of 3 things happens:
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?
3 replies →