Hi, I've made some progress on the FNV code. I expect to be able to advance it, presumably as AD sponsored, before the next IETF.
On DNS Cookies errors, I agree that the utility of the error field, as far as we can see right now, is quite limited. Still, there can be error conditions in the Cookies in queries when the server decides to go ahead and provide a normal full response, so it seems to me desirable to provide a way to return an error code inside the Cookie OPT Option without disturbing the top level RCODE error field. An error is traditional for some "security" enhancements to DNS. See, for example, the error fields in TKEY and TSIG. The big argument against a Cookie error field, that I can see, is that it isn't there in the BIND implementation and running code speaks loudly in the IETF. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Sun, Mar 29, 2015 at 1:30 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > Greetings again. Can one of you summarize the differences between sections > 4/5 and 6/7 in the recent -01 draft? It seems that the error code processing > in 4/5 might either be useful or overkill. > > A related question for Don: how close are you to getting draft-eastlake-fnv > published? For me, it is mandatory for that draft to be stable (and hopefully > published) before we publish draft-ietf-dnsop-cookies in order to make > developers comfortable in deploying cookies without possibly opening servers > and clients to CPU DoS attacks. > > --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
