Issue with the GL #2249 and a possible a miss interpretation of the RFC6891
linked to the the GL #2249 (closed) the response sent back from a server with a status of FORMERR and the OPT set should result in an error message. but if we check in the RFC we can see some different interpretation for that : 6.1.1 : "If an OPT record is present in a received request, compliant responders MUST include an OPT record in their respective responses"
7 : "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." but : "If there is a problem with processing the OPT record itself, such as an option value that is badly formatted or that includes out-of-range values, a FORMERR MUST be returned. If this occurs, the response MUST include an OPT record. This is intended to allow the requestor to distinguish between servers that do not implement EDNS and format errors within EDNS."
so based on the first part of the point 7 : indeed, we could make it as an error ( even if I would be more prone to give a configuration option to still allow the same response as previously ( prior to 9.18 ) as being RFC 100% compliant is good ... but being able to work and understand not RFC compliant servers could help people ).
but if we look at the point 6 , the response should always contain the OPT.
and for the second part of the point 7 : if the software doesn't support 'yet' the EDNS, the the OPT could be seen as out-of-range as everything would be out-of-range as this is not yet supported. In this case, the response containing the OPT could be seen as valid.
PS : I might have miss-understood the RFC but compliancy with not fully RFC compliant sounds more important. PS2 : I saw this issue linked to multiple small DNS providers and on the Microsoft Windows DNS Server (Microsoft DNS 6.1.7601)