<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Greg,<br>
    </p>
    <p>thanks for your insights.</p>
    <p>Ok so the limit of 64 response policy zones applies to one view.</p>
    <p>I wonder, assuming the views are orthogonal (no overlapping of
      CIDRs, as in an ISP assigning CIDRs to local loops):<br>
    </p>
    <p>1. is there an algorithm in bind9 or out there that quickly maps
      a client IP address to a CIDR, e.g. a something like a binary tree
      quicksearch ? or balanced red-black tree ? top-down sequential
      processing sounds very inefficient.<br>
    </p>
    <p>2. if RPZ records are held in memory, why would an RPZ zone need
      to be stored n times if there are n orthogonal views ? That is,
      why the more views the more memory needed. Maybe you meant the
      qpcache, to store different answers, though I don't understand how
      that works.<br>
    </p>
    <p>Best regards<br>
    </p>
    <p>Carlos<br>
    </p>
    <div class="moz-cite-prefix">On 24/08/2024 08:36, Greg Choules
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CANsEUy3zYGS5nga=ZuKsRWNk9aSgdc_gPLeF+Hk9f4T+qZA-pA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Hi Carlos.
        <div>If you have enough RAM it should be possible to create
          multiple views, each with a zone (primary or secondary, up to
          you) that contains the RPZ data for that view and a
          response-policy that uses that zone.</div>
        <div><br>
        </div>
        <div>The limit on number of zones is per response-policy block.
          But if you're using separate blocks inside each view, each r-p
          block referring to only one zone, then that limit is not
          relevant.</div>
        <div><br>
        </div>
        <div>Bear in mind that views are processed top down, so if you
          have a lot of them it can take a (relatively) long time to
          match clients to the ones at the bottom. Also, by default,
          each view has its own cache, hence the need for a lot of RAM.</div>
        <div><br>
        </div>
        <div>I would try it out on a lab server first.</div>
        <div><br>
        </div>
        <div>Hope that helps.</div>
        <div>Cheers, Greg</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Fri, 23 Aug 2024 at 20:43,
          Carlos Horowicz via bind-users <<a
            href="mailto:bind-users@lists.isc.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">bind-users@lists.isc.org</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello
          List,<br>
          <br>
          an ISP has brought a case where several customers do not agree
          with our web interface portal that lets select different RPZ
          zones to be activated for a set of resolvers that are common
          to all customers. They even belong to different countries
          where some domains are banned.<br>
          <br>
          Given the case that I start treating provisioned CIDRs from
          customers as a base for views, does bind9.18.* support a huge
          number of views with different rpz zones activated per view ?<br>
          <br>
          I recall having read in the documentation about a limitation
          of 64 rpz zones in total, is this a number that can be
          configured, or even be set to "unlimited"  ?<br>
          <br>
          Thanks in advance<br>
          <br>
          Carlos Horowicz<br>
          Planisys<br>
          <br>
          -- <br>
          Visit <a
            href="https://lists.isc.org/mailman/listinfo/bind-users"
            rel="noreferrer" target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a>
          to unsubscribe from this list<br>
          <br>
          ISC funds the development of this software with paid support
          subscriptions. Contact us at <a
            href="https://www.isc.org/contact/" rel="noreferrer"
            target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://www.isc.org/contact/</a>
          for more information.<br>
          <br>
          <br>
          bind-users mailing list<br>
          <a href="mailto:bind-users@lists.isc.org" target="_blank"
            moz-do-not-send="true" class="moz-txt-link-freetext">bind-users@lists.isc.org</a><br>
          <a href="https://lists.isc.org/mailman/listinfo/bind-users"
            rel="noreferrer" target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>