At Wed, 6 May 2015 18:33:24 +0000, 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 potentially and unintentionally be biased. I'll try > > to find any such explanation myself, but if someone already knows it > > better can do that, it would also help. > > "Next by thread" from msg13984 has Donald explaining his position, > though not in great detail. If I understand him correctly, he wants to > enable a server to include cookie errors even if it's chosen in this > case to return an otherwise normal NOERROR response to the client.
Okay, so it seems to be a case where the YAGNI principle can apply. On the other hand, on reading the draft and https://www.ietf.org/mail-archive/web/dnsop/current/msg13984.html more closely, I can see some not-so-trivial difference. Assume DNS cookies are deployed sufficiently and some operators start refusing queries without cookies. Then an attacker that wants to spoof a victim client (probably for an amplification attack) would send queries with an invalid server cookie anyway. 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. On the other hand, a server implementation with the separate error code field can choose to send a minimal response with a valid server cookie according to Section 5.2.3 of the draft, thereby minimizing the risk of allowing amplification attacks while still allowing legitimate clients to bootstrap or re-synchronize. In the following part of msg13984.html: >> For (b) retrying should succeed. That said tc=1 would also be just as >> effective at triggering a retry. perhaps Mark tried to say we could achieve the same effect if the server returns a minimal size of response with TC bit on and with the correct server cookie. If it was his intent, it's true to some extent. But these two approaches are not entirely the same since using the TC bit has a side effect of forcing the use of TCP. So the choice does not seem to be a no-brainer to me. But, in the end, I wouldn't be opposed to the idea of removing the separate error code field. The above difference wouldn't be so substantial anyway, and wouldn't justify the introduction of a generic error code field. One last point I'd like to make is that, assuming the above understanding of mine is correct, I'd suggest including the TC bit hack in the initial protocol description. Since it has a side effect it's better to have it sooner so we can update the spec if early deployments suggest the need for it. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
