<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi!</p>
    <p>The problem in unbound exists, because unbound by default creates
      empty authoritative zones for them. You would have to disable
      those empty zones, because their responses are preferred over
      forwarder responses.</p>
    <p>Check output of command: unbound-control list_local_zones<br>
    </p>
    <p>You should see a lot of x.100.in-addr.arpa. lines. You can check
      this by sending "dig @localhost -x 100.64.0.0" and checking flags
      in response. aa flag means local server has generated response and
      it were not received from remote server.</p>
    <p>This can be fixed by having these lines in unbound.conf:</p>
    <p>local-zone: "64.100.in-addr.arpa." nodefault<br>
      local-zone: "65.100.in-addr.arpa." nodefault<br>
      ...<br>
      local-zone: "127.100.in-addr.arpa." nodefault</p>
    <p>Alternatively unblock-lan-zones: yes might fix it also.<br>
    </p>
    <p>Another alternative is to explicitly define forward zones
      instead, which will disable creation of such empty zone of the
      same name. This is what you have found.</p>
    <p>Non obvious problem is that forwarding 100.in-addr.arpa. only is
      less specific than those empty (sub)zones and therefore does not
      prevent creating those, without any warning that most of these
      zones will get blocked results by empty zones.</p>
    <p>Cheers,<br>
      Petr<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 23/03/2025 12:11, Jeremy Beker via
      Unbound-users wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:91FDC3A8-9258-4EDE-AF29-92DAF582706E@confusticate.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      Paul,
      <div><br>
      </div>
      <div>Thanks for the response. While you didn’t address the
        specific question you did point me to the right solution. :)</div>
      <div><br>
      </div>
      <div>One clarification to not besmirch the good folks at
        Tailscale. They are not using the whole 100.0.0.0/8 address
        space. They are only using the 100.64.0.0/10 space from RFC6598.
        And as it is only used internally to their network it won’t in
        most normal configs conflict with ISP usage of the range. </div>
      <div><br>
      </div>
      <div>That said, since DNS has no awareness of CIDR, I was trying
        to “cheat” by being overly broad in my query forwarding by using
        the larger /8. </div>
      <div><br>
      </div>
      <div>The proper solution, which you led me to, was to define
        forward-zones for all 64 “class B” spaces inside the /10 CIDR
        range. Tedious, but doable. </div>
      <div><br>
      </div>
      <div>I’m still curious why a /8 didn’t work, but my immediate
        problem is solved.</div>
      <div><br>
        <div dir="ltr">
          <div><span style="background-color: rgba(255, 255, 255, 0);">-Jeremy</span></div>
          <div><span style="background-color: rgba(255, 255, 255, 0);"><br
                class="webkit-block-placeholder">
            </span></div>
          <span style="background-color: rgba(255, 255, 255, 0);">----</span>
          <div><span style="background-color: rgba(255, 255, 255, 0);">Jeremy
              Beker - <a href="mailto:gothmog@confusticate.com"
                moz-do-not-send="true" class="moz-txt-link-freetext">gothmog@confusticate.com</a></span></div>
          <div><a href="http://www.confusticate.com/"
style="caret-color: rgb(0, 0, 0); background-color: rgba(255, 255, 255, 0);"
              moz-do-not-send="true"><font color="#000000">http://www.confusticate.com</font></a></div>
          <div><span style="background-color: rgba(255, 255, 255, 0);">Condensing
              fact from the vapor of nuance.</span></div>
        </div>
        <div dir="ltr"><br>
          <blockquote type="cite">On Mar 23, 2025, at 02:00, Paul
            Wouters <a class="moz-txt-link-rfc2396E" href="mailto:paul@nohats.ca"><paul@nohats.ca></a> wrote:<br>
            <br>
          </blockquote>
        </div>
        <blockquote type="cite">
          <div dir="ltr"><span>On Sat, 22 Mar 2025, Jeremy Beker via
              Unbound-users wrote:</span><br>
            <span></span><br>
            <blockquote type="cite"><span>I have successfully set up a
                forward-zone for my `ts.net` domain to tailscale’s DNS
                and it works great. I</span><br>
            </blockquote>
            <blockquote type="cite"><span>want to do the same for
                reverse lookups. All tailscale addresses are in the
                100.0.0.0/8 range. So I added</span><br>
            </blockquote>
            <blockquote type="cite"><span>the following to my config
                (via the GUI, but verified in the config file):</span><br>
            </blockquote>
            <span></span><br>
            <span>While not addressing your question, whoever is
              squatting on 100/8 has</span><br>
            <span>picked a pretty bad range. This is in production all
              over the internet,</span><br>
            <span>with the first chunk going to Verisign Business and
              AWS. Perhaps what</span><br>
            <span>was/is intended is to re-use the range 100.64.0.0/10
              which is reserved</span><br>
            <span>by RFC6598 for CGNAT and should not appear in the
              public internet?</span><br>
            <span></span><br>
            <blockquote type="cite"><span># Forward zones</span><br>
            </blockquote>
            <blockquote type="cite"><span>forward-zone:</span><br>
            </blockquote>
            <blockquote type="cite"><span>  name: "100.in-addr.arpa"</span><br>
            </blockquote>
            <blockquote type="cite"><span>  forward-addr:
                100.100.100.100</span><br>
            </blockquote>
            <span></span><br>
            <span>As 100.100.100.100 is part of 100.64.0.0/10.</span><br>
            <span></span><br>
            <blockquote type="cite"><span>This does not seem to work.
                Any request to look up an address (like 100.94.184.34)
                returns:</span><br>
            </blockquote>
            <span></span><br>
            <span>Who is 100.94.184.34 ? That must be one of your own or
              part of the</span><br>
            <span>tailscale re-use of 100.64.0.0/10 ?</span><br>
            <span></span><br>
            <span>Perhaps limiting your range to 100.64.0.0/10 will
              prevent you mixing up</span><br>
            <span>this tailscale universe with the public DNS universe?</span><br>
            <span></span><br>
            <span>Paul</span><br>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Petr Menšík
Senior Software Engieer, RHEL
Red Hat, <a class="moz-txt-link-freetext" href="https://www.redhat.com/">https://www.redhat.com/</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
  </body>
</html>