> On 22 Mar 2018, at 10:30 pm, Ralph Dolmans <ra...@nlnetlabs.nl> wrote: > > Hi, > > On 21-03-18 16:58, Petr Špaček wrote: >> draft-spacek-edns-camel-diet-00 is a new draft which partially reacts to >> The Camel talk from yesterday, and is based on plan of open-source DNS >> software vendors to get rid of EDNS workarounds. > >> From the introduction: > >> EDNS version 0 was standardized in 1999, but non-RFC 1035 compliant >> implementations still exist and cause lot of extra queries and >> complicated logic in recursive resolvers. RFC 6891 clearly states >> that FORMERR is the only acceptable answer for implementations >> without support for EDNS. > > This is, although factual correct, somewhat misleading. Yes EDNS0 is > standardized in 1999, but that is not the later mentioned RFC6891 (from > 2013) that requires a FORMERR RCODE. RFC2761 from 1999 talks about > "NOTIMPL, FORMERR, or SERVFAIL". I also fail to understand the relation > with RFC1035 in the first sentence.
RFC 1035 says to return FORMERR to a EDNS request. Yes, RFC 1035 said how to handle unknown extensions. That is what the expected behaviour of a STD 13 compliant server *is*. Non STD 13 compliant servers returned NOTIMPL and SERVFAIL. RFC2761 reported what was seen in the wild. FORMERR was the dominate rcode at the time. I don’t see anything other than FORMERR or NOERROR these days to a plain EDNS(0) query from a non-EDNS aware server. > Also the "The Protocol" section does not mention that the retrieved > RCODE (if any) is relevant in the decision whether to retry with or > without EDNS. > > -- Ralph > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
