On 14/12/2015, at 19:20, "zuop...@cnnic.cn" <zuop...@cnnic.cn> wrote:
> 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? Cookies is designed to work with stub resolvers. Add a couple of bytes of shared memory and you can preserve the server cookies across multiple clients without hitting disk. As for not having a server cookie you just send the request without a server cookie and you will get back a answer or badcookie with a server cookie and in that case you resend the query with the learnt server cookie. > 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. And that was on of the reasons for cookies. > > the main differences between a RQID and a cookie are: > 1)RQID is stateless, nothing has to be cached; Cookies can be completely stateless. > 2)low calculation cost for RQID So is cookies. > 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
