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

["[e-mail]" <[e-mail]>]

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!



[e-mail]
 
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 <[e-mail]>, Stephane Bortzmeyer writes:
> On Fri, Dec 11, 2015 at 09:21:32AM -0800,
>  [e-mail] <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]