Carry DNSSEC evidence and show the risk

A cut is a caching inference, not cryptographic validation or complete attack protection.

• A validating resolver MAY restrict NXDOMAIN cuts to responses validated with DNSSEC. Under that chosen policy, an unvalidated answer does not create this descendant shortcut. This is an allowed restriction, not a claim that RFC 8020 requires every NXDOMAIN cut to be DNSSEC-validated (§§2,7). Ordinary handling of the original negative response is outside the selected cut-only helper.
• For a cached nonexistence response from a DNSSEC-signed zone, accompanying NSEC or NSEC3 records authenticate the denial. The same set proves the descendant denial. The iterative caching resolver MUST return these records when the triggering query has DNSSEC OK (DO) set (§2). The drawing carries opaque proof identifiers; no signature verification or proof construction is implemented.
• If DO is not set, this particular MUST-return requirement is not triggered. This does not mean that all DNSSEC records are forbidden in every such response, or that clearing DO makes an answer trustworthy. DO asks to receive DNSSEC records; it is not itself validation (§2).
• A forged unsigned NXDOMAIN can poison a cache and hide a larger subtree through this optimization. DNSSEC validation addresses forged denial evidence; it does not encrypt names, guarantee availability or make an erroneous teaching-model flag authentic (§7). The attacker path is stopped at the selected validating-policy gate before a descendant cut is installed.
• RFC 8020 §5 notes a split internal-forwarding setup can conflict with a public cached denial, and does not require support for that setup. This guide does not recommend configuration changes. Its §4 benefits do not promise protection against every random-name attack. Related RFC 8198 describes broader aggressive use of DNSSEC-validated negative cache, which is separate from this ancestor NXDOMAIN inference (Appendix B; RFC 8198 §5).