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

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 11 Dec 2015 18:30:28 +0100

On Fri, Dec 11, 2015 at 09:21:32AM -0800,
 [email-masked] <[email-masked]> 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).

If there is a difference, and a reason why you just don't use DNS
cookies, please document it.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 12 Dec 2015 10:15:29 +1100

> 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

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 14 Dec 2015 16:20:24 +0800

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!

[email-masked]
 
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

 

Mark

---

From: Mark Andrews <[email-masked]>
Date: Mon, 14 Dec 2015 20:40:53 +1100

> 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. 

> using fixed port numbers, it mainly aims to work between recursive servers and authorized 

And that was on of the reasons for cookies. 

> 1)RQID is stateless, nothing has to be cached;

Cookies can be completely stateless. 

> 2)low calculation cost for RQID

So is cookies.