In message caje_bqc0unc6dtsjls8oeeka2mexxphbgijqaxfn7_awvq_...@mail.gmail.com
, =?UTF-8?B?56We5piO6YGU5ZOJ?= writes:
At Wed, 6 May 2015 18:33:24 +,
Evan Hunt e...@isc.org wrote:
Can someone explain why we'd need the separate error codes based on
the position of supporting them (i.e,
At Wed, 6 May 2015 18:33:24 +,
Evan Hunt e...@isc.org wrote:
Can someone explain why we'd need the separate error codes based on
the position of supporting them (i.e, not to persuade others on
dropping them)? msg13984.html was basically written to argue against
them, so it could
On Thu, May 07, 2015 at 09:11:53AM -0700, 神明達哉 wrote:
According to Section 7.2.4.1 of draft-ietf-dnsop-cookies-01, the server
will still return the full size of response, so the attack will still be
effective.
Subject to rate limiting restraints, yes. BIND's experimental SIT
implementation
It appeared from me from the meeting in Dallas and the sparse list
discussion is while the error codes would seem interesting/useful,
there is no good use case to show usefulness, which is my Mr. Andrews
did not implement them.
I was approaching this (and as we approach the idea of WGLC)
At Fri, 1 May 2015 23:21:30 +,
Evan Hunt e...@isc.org wrote:
The chief difference between the two is the presence of an error code field
in Eastlake cookies; Andrews found it redundant/unnecessary (as discussed
in https://www.ietf.org/mail-archive/web/dnsop/current/msg13984.html).
The
Evan,
On Friday, 2015-05-01 23:21:30 +,
Evan Hunt e...@isc.org wrote:
Speaking for myself, I agree with Mark: the benefits of including
error codes in the option are slim and other mechanisms such as
FORMERR work just as well in almost every scenario, so it doesn't
justify the cost in
Greetings,
The current DNS Cookies document (draft-ietf-dnsop-cookies-01) has two
similar but distinct protocols described in it: the DNS Cookie option as
designed by Donald Eastlake, and the Simple DNS Cookie option designed by
Mark Andrews and experimentally implemented (under the name Server
On May 1, 2015, at 4:21 PM, Evan Hunt e...@isc.org wrote:
Speaking for myself, I agree with Mark: the benefits of including error
codes in the option are slim and other mechanisms such as FORMERR work
just as well in almost every scenario, so it doesn't justify the cost in
additional
