> On 22 Feb 2016, at 23:24, Mark Andrews <ma...@isc.org> wrote: > > > Strictly speaking the additional section can have anything the > server feels is relevent including a OPT record (this in RFC 1034). > Clients are expected to cope with anything added to the additional > section. > > 6. Using local data only, attempt to add other RRs which may be > useful to the additional section of the query. Exit. > > That said it is pointless to add a OPT record unless you know the > client understands OPT. Using a extended rcode would also be > problematic as they require that the client understand OPT records > which can't be determined unless you have see a OPT in the request. > > Unknown EDNS options are expected to be ignored in both requests > and replies so it is safe to add a unknown EDNS option to either. > > This actually means you can add this option to any response but I > would limit it to responses where there was a OPT record in the > request.
Just to clarify, the draft already specifies that restriction, based on this text from RFC6891 (https://tools.ietf.org/html/rfc6891#section-7 <https://tools.ietf.org/html/rfc6891#section-7>) : “Lack of presence of an OPT record in a request MUST be taken as an indication that the requestor does not implement any part of this specification and that the responder MUST NOT include an OPT record in its response.“ Sara.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
