xNAME RCODE and Status Bits Clarification
updates
Extracted elements (10)
When following an xNAME chain, all but the last query cycle necessarily had no error—otherwise the chain would have terminated earlier. Therefore, setting RCODE based on the final cycle is logically correct and fully describes the outcome of the complete resolution process.
RFC 2308 Section 2.1 implies RCODE should be set from the last query cycle in an xNAME chain, but RFC 2308 Section 2.2.1 acknowledges that some servers do not follow this behavior. RFC 6604 resolves this ambiguity by mandating the final-cycle RCODE rule.
The clarifications of AA and AD bit behavior in Sections 2.1 and 2.2 are restated from RFC 1035 and RFC 4035 unchanged. They are repeated here because released implementations were observed not following these meanings in xNAME chain scenarios.
When an xNAME chain is followed, the RCODE in the ultimate DNS response MUST be set based on the final query cycle leading to that response. If the chain terminated by an error, the error code is used; if terminated without error, RCODE is zero.
An xNAME chain is a series of one or more xNAMEs each of which refers to another xNAME except the last, which refers to a non-xNAME or results in an error. Chains may cross multiple authoritative zones and involve multiple query cycles.
The AA (Authoritative Answer) bit in a DNS response header is set based on whether the server providing the answer with the first owner name in the answer section is authoritative. In an xNAME chain, this reflects the authority status of the first xNAME encountered, not subsequent redirections.
The AD (Authentic Data) bit is set in a DNS response header only if the DNSSEC-enabled server believes all RRs in the answer and authority sections of that response to be authentic. This requirement applies across the entire response, not just the final query cycle of an xNAME chain.
xNAME RRs are resource records such as CNAME and DNAME that cause a DNS query to be redirected to a different name. When encountered during resolution of a different query type, the xNAME RR (and any synthesized CNAME) is added to the response answer, and the query is restarted with the redirected name.
The AA header flag bit is not protected by DNSSEC. To secure it, secure communications between the querying resolver and the DNS server are needed, such as DNS transaction security via TSIG (RFC 2845) or SIG(0) (RFC 2931).
The AD bit and RCODE in a DNS response are not in general protected by DNSSEC. They are protected only when: the relevant zones are signed, DNSSEC RRs are requested and provided in responses, and the querier has appropriate trust anchors and validates the DNSSEC RRs.