Comment by zamadatix

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.