<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    On 17-Feb-22 16:45, Randy Bush wrote:
    <blockquote type="cite" cite="mid:%3Cm2fsohqi9g.wl-randy@psg.com%3E">
      <pre class="moz-quote-pre" wrap="">for some reason lost in time, i have the following in `/etc/ipfw.rules`
on a freebsd system running bind9

    add allow tcp from any to me 53 limit src-addr 1 setup
    add deny tcp from any to me 53

the results are

    01000  48358531   6390772849 allow tcp from any to me 53 setup limit src-addr 1 :default
    01100    165225      9379997 deny tcp from any to me 53

is this about normal?

randy
</pre>
    </blockquote>
    <p>This seems like an artifact of a time when people assumed that
      TCP use was rare (and expensive), and likely only used for zone
      transfers.  Were that the case, this would have been an attempt to
      protect against denial of service attacks.<br>
    </p>
    <p>This was always a bad assumption.  With today's larger responses
      & traffic profiles, if it ever made sense, it's long past its
      expiration date.  TCP is required, and no RFC requires a client
      (or clients) on a host to minimize the number of TCP connections. 
      Nor to limit the number of active zone transfers per host.</p>
    <p>The effect is likely to be that client responses are slow and/or
      pushed away from this server to one that's more tolerant.  Whether
      the 165K dropped connections are significant is impossible to tell
      without (a) knowing the amount of time it represents and (b) what
      those attempts were trying to do.  They represent about 0.3% of
      the traffic in this interval - but that doesn't measure their
      importance.<br>
    </p>
    <p>Since you don't have a specific rationale for the rule based on a
      known situation, I would remove it.  (More precisely, remove the
      limit, which means replacing these rules with something like
      'allow tcp from any to me 53'.)  If that results in abusive
      traffic, another (traffic-specific) approach to dealing with it
      would be in order.  And if it comes to that, do yourself (and your
      successors) a favor and document the problem you encounter and how
      your solution works...</p>
    <pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. </pre>
    <p><br>
    </p>
  </body>
</html>