<div dir="ltr">The problem that I ran into is that different queries in the same domain were all considered the same by the RRL code, so a single client loading a web page could easily hit the limit and be slowed down by the dropped responses.  If you set the "IPv4-prefix-length" to "32", and "slip" to "1", and a high "responses-per-second", it might be workable, but I have not dared to inflict it on my users yet.<br>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>If I open a browser (that I think does local caching) and go to "<a href="http://hp.com">hp.com</a>" note that for example a query for "<a href="http://h10120.www1.hp.com">h10120.www1.hp.com</a>" is seen by RRL as another of many queries for "<a href="http://hp.com">hp.com</a>", and gets rate-limited:</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra"><div class="gmail_extra">09-May-2013 10:01:48.165 queries: info: client MY-IP#55435: query: <a href="http://h10120.www1.hp.com">h10120.www1.hp.com</a> IN A + (MY-DNS)</div>
<div class="gmail_extra">09-May-2013 10:01:48.165 queries: info: client MY-IP#55435: drop referral to <a href="http://141.213.135.0/24">141.213.135.0/24</a> for <a href="http://hp.com">hp.com</a> IN A  (000030ec)</div><div>
<br></div><div style>If I could fix it so that RRL is based on the actual query, or the complete response, being the same, then it would probably work reasonably for a recursive server, with caching clients.</div><div><br>
</div><div>-- <br>Bob Harold<br>hostmaster, UMnet, ITcom<br>Information and Technology Services (ITS)<br><a href="mailto:rharolde@umich.edu" target="_blank">rharolde@umich.edu</a><br>734-647-6524 desk<br></div>
<div class="gmail_extra"><br></div><br>Date: Thu, 9 May 2013 10:07:20 +1200<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

From: Jay Daley <<a href="mailto:jay@nzrs.net.nz">jay@nzrs.net.nz</a>><br>
To: "<a href="mailto:ratelimits@lists.redbarn.org">ratelimits@lists.redbarn.org</a>" <<a href="mailto:ratelimits@lists.redbarn.org">ratelimits@lists.redbarn.org</a>><br>
Subject: Re: [ratelimits] rate limiting recursive server<br>
Message-ID: <<a href="mailto:359330F0-025B-4401-84C2-3DD7289BA130@nzrs.net.nz">359330F0-025B-4401-84C2-3DD7289BA130@nzrs.net.nz</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
On 18/04/2013, at 2:13 PM, Vernon Schryver <<a href="mailto:vjs@rhyolite.com">vjs@rhyolite.com</a>> wrote:<br>
<br>
> ...<br>
> That implies that the server isn't used by SMTP servers, HTTP clients,<br>
> or other applications that send bursts of identical DNS requests.<br>
> ...<br>
<br>
Does anyone know of any studies done or other evidence that would help understand exactly what would break (or slow down) if RRL were used on a recursive resolver?  For example has anyone looked at traffic being received by a recursive resolver, identified bursts of identical DNS requests and then analysed those to find out what the client is that generates them and what percentage of their traffic they are?<br>

<br>
Correct me if I'm wrong but I get the impression that caching is increasingly being added to clients either directly in the code or indirectly through the OS and so over time bursts of identical DNS requests will reduce in frequency as clients are upgraded?<br>

<br>
cheers<br>
Jay<br>
<br>
--<br>
Jay Daley<br>
Chief Executive<br>
.nz Registry Services (New Zealand Domain Name Registry Limited)<br>
desk: <a href="tel:%2B64%204%20931%206977" value="+6449316977">+64 4 931 6977</a><br>
mobile: <a href="tel:%2B64%2021%20678840" value="+6421678840">+64 21 678840</a><br>
linkedin: <a href="http://www.linkedin.com/in/jaydaley" target="_blank">www.linkedin.com/in/jaydaley</a><br></blockquote></div></div></div>