Attach the cut to the denied name

Use the final denied name, never widen a cut from an SOA owner.

• QNAME is the name in the question section. With CNAME or DNAME redirection, the denied name can differ: the NXDOMAIN refers to the end of the alias chain, not automatically the original QNAME. A CNAME maps one owner name to a target; DNAME redirects descendants. This guide’s concrete example uses CNAME only (§§1.1–2; RFC 6604 §§1,3).
• In the selected chain www.example. CNAME gone.example., followed by NXDOMAIN, gone.example. is denied. www.example. still has the alias record. Cache the cut at the final name; do not mark the original alias owner nonexistent. RFC 6604 §3 requires the final response RCODE to reflect the last query cycle (MUST).
• The SOA (Start of Authority) record accompanying a negative answer identifies the zone apex and carries negative-caching timing. Its owner is not the closest existing name. NXDOMAIN for a.gone.example. with SOA owner example. does not prove gone.example. or example. nonexistent (Appendix A).
• If the first queried denied name is a.gone.example., a later b.gone.example. is a sibling, not a descendant of the denied node. The first NXDOMAIN does not cover it. The resolver may need normal resolution; it cannot invent a wider cut merely because a shared suffix or SOA looks convenient (§2, Appendix A).
• The bounded helper follows a selected, explicitly ordered CNAME chain and rejects loops/broken links as local input errors. It does not implement DNAME rewriting, wildcard proofs or a complete DNS parser. Limits and error statuses are teaching choices, not new protocol requirements.