RFC 6672 saith:
A CNAME RR with Time to Live (TTL) equal to the corresponding DNAME
RR is synthesized and included in the answer section when the DNAME
is employed as a substitution instruction. The DNSSEC specification
([RFC4033] [RFC4034] [RFC4035]) says that the synthesized CNAME does
not have to be signed. The signed DNAME has an RRSIG, and a validating
resolver can check the CNAME against the DNAME record and validate the
signature over the DNAME RR.
The phrase "included in", as opposed to "appended to", provides no guidance
about the order in which records appear, so presumably it's legal to have
the synthesized CNAME appear first and the DNAME from which it was
synthesized afterward.
Most implementations, however, do send the DNAME first. We had a problem
with BIND a while back when we encountered a server that didn't. BIND
processes the RRsets in an answer in the order they're received (I suspect
nearly all resolvers do this). In this case, the decisions about how to
validate and cache the CNAME went wrong because we didn't have the flag set
saying we'd previously seen a DNAME.
We rejiggered the code so it wouldn't care about the order of records
anymore (incidentally, and embarrassingly, introducing another bug in the
process, but that's another story). It would have been simpler and more
painless if we could have just treated this condition as a FORMERR.
I'd like to start a discussion of that now. Does anyone have a problem
with the idea of clarifying the protocol here, saying that the order of
records in the answer section of a chaining response is significant, and in
particular, that a DNAME MUST precede the corresponding synthesized CNAME?
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
