<div dir="auto">So why doesn’t it work to make your limited server authoritative for the root and only forward the zones you want? Anything that isn’t in a forwarded zone does not exist (except the root itself).</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 17, 2021 at 11:07 PM Marki <<a href="mailto:bind-users@lists.roth.lu">bind-users@lists.roth.lu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
  
    
  
  <div>
    <p><br>
    </p>
    <div>On 4/14/2021 12:44 AM, Sebby, Brian A.
      via bind-users wrote:<br>
    </div>
    <blockquote type="cite"><br>
      <p class="MsoNormal">My situation is due to a security
        requirement.  We have DNS servers at our site running BIND that
        allow recursion, but I’ve been requested to set up some
        additional DNS servers for another project that is expected to *<b>only</b>*
        access the data that we’re authoritative for.  And of course ….
        there’s a chance that it might need to look up one or two
        external zones.  Essentially, what I really need is a recursive
        whitelist that doesn’t tell BIND what clients are allowed to do
        recursive lookups, but to limit BIND to only allow recursive
        lookups on a very small list of allowed domains.<u></u><u></u></p>
      <p class="MsoNormal"><u></u> <u></u></p>
      <p class="MsoNormal">I was trying to set up a forwarding zone to
        forward queries to our DNS servers that do allow recursion, but
        as I discovered (and as was discussed earlier in the thread), if
        recursion is not allowed, then forwarding is also not allowed. 
        I had tried setting the “allow-recursion” field to “localhost”
        and setting up a forward zone to forward to 127.0.0.1, but that
        didn’t work either.<u></u><u></u></p>
      <br>
    </blockquote>
    <p>Hello,<br>
    </p>
    <p>So they do _not_ only look up internal/authoritative zones, but
      external ones as well. (It's always the exceptions that kill you.)<br>
    </p>
    <p>I think we have previously established that there is not a good
      way to do whitelisting using Bind, see the thread "Authority and
      forwarding, but not recursion/iteration".</p>
    <p>If you can live with non-allowed zones returning SERVFAIL
      (instead of NXDOMAIN for example), then using a recursive service
      with a bogus global forwarder and static stubs pointing to the
      authoritative/non-recursive service might do the trick.</p>
    <p>You might also be able to leverage RPZ if there are no complex
      conditions associated to your rules (everyone will have the same
      white/blacklists). You configure passthrough for the allowed zones
      and deny the rest.</p>
    <p>Alternatively, there is dnsdist which, while being a
      load-balancer, could be considered the swiss army knife of DNS
      filtering.</p>
    <p>Finally, some firewalls like Fortigates provide a "DNS filter"
      that lets you define custom white and blacklists. Palo Altos
      currently are not able to whitelist AFAIK.</p>
    <p>Best regards,</p>
    <p>Marki<br>
    </p>
  </div>

_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">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">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">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div></div>