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

* 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