These two paragraphs don't match reality. Lots of servers, incorrectly, just set the rcode to FORMERR, set QR to 1 and return the request message. If we want to distingish FORMERR from EDNS aware servers we need to provide a signal that works. The signaling described here doesn't.
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. 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. Setting a EDNS header flag in the response could provide such signaling. Additionally there are lots of servers that just ignore the OPT record in the request and send back a response without a OPT record the answers the query section. I would argue that this is a better response if you don't want to support EDNS than returning FORMERR which should drop to a MAY from the MUST above. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
