On 30/10/2018 16:57, Wes Hardaker wrote:
> Well, the plan is to not allow it per the original EDNS0 spec. We > should have said that in the section and said "going once...." or > something. IE, the plan is to disallow sending it back unless the > source indicates support. > > [In theory, it should be possible to always include it because of the > "ignore additional you don't understand" rule] Except that RFC 6891 expressly prohibits that (§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. FWIW, I really wish in retrospect that EDNS(0) had defined the extra rcode bits as being for a _sub-type_ of the primary RCODE, i.e. SERVFAIL is always "2" in those four bits in the main header, with the extended field in the EDNS response allowing for more detail (c.f. this draft). Unfortunately with the newer RCODEs just being assigned contigiously from 16 onwards that's no longer possible :( As it is, if you send extended RCODE 18 (BADTIME) in a packet a non EDNS-aware client will only see RCODE 2, which is probably in large part why we have the very stricture quoted above. Ray
pEpkey.asc
Description: application/pgp-keys
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
