Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt

i don't think we could introduce that feature and still call this EDNS(0)

Joao

On 13 Feb 2012, at 07:06, Florian Weimer wrote:

> * Olafur Gudmundsson:
> 
>> This draft closes all issues identified so far.
> 
> I'm still worried that this specification does not provide much
> guidance how to determine whether an authoritative server supports
> EDNS.
> 
> This requirement
> 
>   Responders which 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 RR in the additional section
>   and MUST NOT include an OPT record in the response.
> 
> (section 8) updates RFC 1035.  This should be reflected in the
> document header.  I think this paragraph is too strict, the actual
> requirement is "MUST respond with FORMERR or process the query as if
> no OPT RR was present".  The "MUST NOT include an OPT record in the
> response" part is still a (minor) update to RFC 1035.  Originally, it
> was possible to generate FORMERR responses by flipping the QR bit and
> sending back the question packet.
> 
> Section 9 should mention that mistakenly disabling EDNS might lead to
> a denial of service.  Such a failure could be caused by a query which
> results in a FORMERR response, while other queries to the same server
> would not.
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext