Re: [DNSOP] I-D Action: draft-lee-dnsop-recursion-performance-improvement-00.txt

On 14/12/2015, at 19:20, "zuopeng@cnnic.cn" <zuopeng@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!
> 
> zuopeng@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.GA27573@nic.fr>, Stephane Bortzmeyer writes:
> > On Fri, Dec 11, 2015 at 09:21:32AM -0800,
> >  internet-drafts@ietf.org <internet-drafts@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: marka@isc.org