thanks for your comment! i just read draft-ietf-dnsop-cookies and it seems this draft is much more approriate to work between stub resolves and recursive resolvers. it provides authentication for both sides to improve security. but for outbound requests, a recursive server may not benefit a lot because of the calculation and extra cache cost. besides, i am also not clear about how it rejects forged requests. for every first request, the client has no server cookies, how can the server recognize these requests?
actually, we initially came up with this RQID draft to improve recursion performance using fixed port numbers, it mainly aims to work between recursive servers and authorized servers. the main differences between a RQID and a cookie are: 1)RQID is stateless, nothing has to be cached; 2)low calculation cost for RQID also, your suggestion of not just accepting responses without the option but fall back to port randomisation is helpful, we will supplement this to our new version. thanks! zuop...@cnnic.cn From: Mark Andrews Date: 2015-12-12 07:15 To: Stephane Bortzmeyer CC: draft-lee-dnsop-recursion-performance-improvement.all; dnsop Subject: Re: [DNSOP] I-D Action: draft-lee-dnsop-recursion-performance-improvement-00.txt In message <20151211173028.ga27...@nic.fr>, Stephane Bortzmeyer writes: > On Fri, Dec 11, 2015 at 09:21:32AM -0800, > internet-dra...@ietf.org <internet-dra...@ietf.org> wrote > a message of 42 lines which said: > > > Title : An approach to improve recursion performance > > Authors : Xiaodong Lee > > Hongtao Li > > Haikuo Zhang > > Peng Zuo > > Filename : draft-lee-dnsop-recursion-performance-improvement-00. > txt > > At the first reading, I do not see the difference between your RQID > and a cookie, as documented in draft-ietf-dnsop-cookies (currently > past working group last call and sent to the IESG). It's half of the client half/part of a cookie. I would also suggest not just accepting responses without the option but rather fall back to port randomisation. We were planning to switch back to a fixed port. The only question was for the first query and retry with a random port if one didn't get the cookie option in a reply or to only send using the fixed port when you know that cookies are supported by the server. The choice of which strategy to employ is really dependent on the uptake of cookie support in servers. At 50%+ deployment the first strategy should give the greatest benefit. Before that the second strategy should be the winning one. Mark > If there is a difference, and a reason why you just don't use DNS > cookies, please document it. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
