* Paul Vixie: >> As a counterexample, RFC 6891 requires FORMERR responses without OPT >> RRs from implementations which do not support EDNS: >> >> Responders that choose not to implement the protocol extensions >> defined in this document MUST respond with a return code (RCODE) of >> FORMERR to messages containing an OPT record in the additional >> section and MUST NOT include an OPT record in the response. > > this language was very careful. older implementations cannot > "choose" behaviour relative to this standard. so, as an example of > what you're trying to convey, this text fails.
They could patch the RCODE in the header and reflect the packet. That used to be a valid implementation option, and it was sort-of assumed by the previous EDNS0 version with its extended label types. It was the only way to generate a FORMERR response when you could not parse even the QNAME. (Or you could say that EDNS0 encouraged matching responses based on transaction IDs only, but let's not go there.) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
