[DNSOP] RFC6891 Section 7. Transport Considerations

[Mark Andrews <[e-mail]>]

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:	[phone]		         INTERNET: [e-mail]