Re: [DNSOP] New Version Notification for draft-spacek-edns-camel-diet-00.txt

> On 22 Mar 2018, at 10:30 pm, Ralph Dolmans <ralph@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: marka@isc.org