<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>If you are dealing with two totally private networks, do you even
      need the ACL?</p>
    <p>But if you do need to limit access, then I suggest using TSIG to
      identify and authorize. This avoids the whole question of
      source/destination IP addresses. If the transfer request is made
      using the correct key, it will work.</p>
    <p>I do this by defining a specific key for each secondary server.
      Then, in the appropriate view on the hidden primary, I use:</p>
    <p><font face="monospace">  match-clients { none; };<br>
          allow-transfer { key nameofkeyhere; };</font></p>
    <p>and on each secondary, I define a 'primaries' and use that in the
      zone definitions:</p>
    <p><font face="monospace">  primaries hiddenprimary { 10.20.30.40
        key nameofkeyhere; };<br>
          zone "foo.bar.com" { type secondary;  primaries {
        hiddenprimary; }; };</font></p>
    <p>The address of the secondary does not matter. As long as it makes
      the connection to the primary using the key 'nameofkeyhere', it
      can do the zone transfers.<br>
    </p>
    <pre class="moz-signature" cols="72">--
Do things because you should, not just because you can. 

John Thurston    907-465-8591
<a class="moz-txt-link-abbreviated" href="mailto:John.Thurston@alaska.gov">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska

</pre>
    <div class="moz-cite-prefix">On 9/6/2022 2:31 PM, Greg Choules via
      bind-users wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CANsEUy3Qj4nXBqnyWQBiEs-=xn26fEWMTPsAxSQ=d7YGbp5XSg@mail.gmail.com">
      
      <div>
        <div dir="ltr">Hi Michael.
          <div>Have you tried without the "allow-transfer" statements at
            all? I find it usually works best to start simple, get it
            working, then apply security bit by bit.</div>
          <div>Do you have logs from all servers? What are they telling
            you specifically about what is the issue?</div>
          <div>Lastly, get packet captures of port 53. Evidence is
            always handy to see what is actually going on, rather than
            guessing what you *think* should be going on.</div>
          <div><br>
          </div>
          <div>Cheers, Greg</div>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Tue, 6 Sept 2022 at
            23:16, Michael De Roover <<a href="mailto:isc@nixmagic.com" moz-do-not-send="true" class="moz-txt-link-freetext">isc@nixmagic.com</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 everyone,<br>
            <br>
            I have currently 2 internal networks under my control, both
            of which have BIND <br>
            name servers in them. The "main" network uses the <a href="https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.10.0%2F24&data=05%7C01%7Cjohn.thurston%40alaska.gov%7C0b4f0d284fe74f09bbf108da9057ba85%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C637981003716453668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m4PWz1DpiHERIwtojthnVS%2FqlwZSOVlo2b92ppc2UQs%3D&reserved=0" originalsrc="http://192.168.10.0/24" shash="SyRGIE4cWCop30A57ujSebUtch2ddEv5//KXXJDSjBaIEPno3kU8/wudOoqpAjh2FyDwWYaSvFPzVUlL3OQtw9JcVUireGm7Qpm1Jlx5QvKl5lnPERfhOOMbk/NmBb+uRJHNrd/rKudeLa6hgX+rlciELaSs54JugYfps0Wvy8U=" rel="noreferrer" target="_blank" moz-do-not-send="true">
              192.168.10.0/24</a> subnet, <br>
            while the "satellite" network uses the <a href="https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.20.0%2F24&data=05%7C01%7Cjohn.thurston%40alaska.gov%7C0b4f0d284fe74f09bbf108da9057ba85%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C637981003716453668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ip1uyLLXepntzC%2BEY1IHwUBmbRaMcP9l4z6W6VDJ0e8%3D&reserved=0" originalsrc="http://192.168.20.0/24" shash="rfIA6aEoEJv+fpps7mT6gHziPgx8tCWuURLng/fmxEUcyvMrcg8WTuaUKXGXWkwDgNP2UsJ5qQihPKhkh+77GDiM8tuHEQgnH/BYYf9bSnBgWaPCOBa1pYYMAUFw4GlWRJ/lsaDY90u1ewlQKZ6vwGBGXQABwcwoH1DYkjHFhXc=" rel="noreferrer" target="_blank" moz-do-not-send="true">
              192.168.20.0/24</a> subnet. Following this, <br>
            I will refer to these as main and satellite. You may
            consider the satellite <br>
            network sort of like a road warrior setup, though both are
            fully-fledged <br>
            networks with hosts in them.<br>
            <br>
            The main network has a set of two gateways with IP addresses
            192.168.10.51, <br>
            and 192.168.10.52. They perform VRRP to each other, with
            floating IP <br>
            192.168.10.9. Both of them make a VPN connection to two
            VPS's using WireGuard.<br>
            <br>
            The VPS's have IP ranges <a href="https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.8.2.0%2F24&data=05%7C01%7Cjohn.thurston%40alaska.gov%7C0b4f0d284fe74f09bbf108da9057ba85%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C637981003716453668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6An6ZttdBhIJDCfAW2uPJ7l3hcwAWdBmoVcGq3SFJSY%3D&reserved=0" originalsrc="http://10.8.2.0/24" shash="JPpV0L0zUZnnf7CvPPzPjXwIzn5GGeQZO4vxIZOHizMTtyzBsttkJqdhFruFSKGBF05r0uflkX/N1lwNxYwyjSuEoFVjxe9cpTe9enDM1rGY2q2g8eH/qydc3g/D6nieTLXGjUQIsMOO0jijPk26yuqEozaJyGef/oKn85g/T6g=" rel="noreferrer" target="_blank" moz-do-not-send="true">
              10.8.2.0/24</a> and <a href="https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.8.3.0%2F24&data=05%7C01%7Cjohn.thurston%40alaska.gov%7C0b4f0d284fe74f09bbf108da9057ba85%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C637981003716610384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IAbKqjHmQi9WoT67xkh0oXkM9mk78n2w0DJZtkNM0Po%3D&reserved=0" originalsrc="http://10.8.3.0/24" shash="RXWGbSuwWnFpu+A3ThgEfGnc79yeu4RSI6iw0CDxAnEJlAdzkDLuA+C1IK2eIQxbazHXdTI4yGHE3bEvI3zHS2MdQH1k+t8dglt3XYql3H9u4Z8xtJKfIya4qPQwF8lvo2hy2nTXj3eRNPDkuDhKy7XgkmRJ9RbtH91mAoQnFLc=" rel="noreferrer" target="_blank" moz-do-not-send="true">
              10.8.3.0/24</a> respectively. Pretty much <br>
            all traffic that's relevant here (AXFR/IXFR on TCP 53) goes
            through the former.<br>
            <br>
            The satellite network does the same thing, it also connects
            to the VPS's but <br>
            does not perform VRRP with another node. The gateway on the
            satellite network <br>
            uses IP address 192.168.20.1.<br>
            <br>
            The name servers on these networks are 192.168.10.4,
            192.168.10.5 and <br>
            192.168.10.6 on the main network, and 192.168.20.3 on the
            satellite network.<br>
            <br>
            This is running on BIND 9.16.25 for Alpine on the main
            network, and BIND <br>
            9.11.5-P4-5.1+deb10u7-Debian for Debian on the satellite
            network. All of them <br>
            are running in LXC with bridged networking.<br>
            <br>
            Now I would like to get both of these networks to share
            their local zones. So <br>
            in the name servers' configs I would initially declare an
            ACL for this and add <br>
            that to the zone entries, on the main network. This worked
            fine for those, <br>
            being in the same subnet. But once I tried to do the same on
            the satellite <br>
            network, BIND on the main network would see the zone
            transfer as coming from <br>
            192.168.10.51 or 192.168.10.52 -- instead of coming from
            192.168.20.3 -- and <br>
            refuse it. The same is true the other way around, where the
            name server on the <br>
            satellite network sees zone transfers from the main network
            as coming from <br>
            192.168.20.1 instead.<br>
            <br>
            In other words, only the first hop (or the last, depending
            on how you look at <br>
            it) is being considered, with zone transfers seemingly being
            expected to occur <br>
            from within the same subnet. Surely I'm not the only one who
            dealt with this? <br>
            If anything, I consider myself still a newbie. Is it
            possible to get BIND to <br>
            consider the original source of the zone transfer instead?<br>
            <br>
            For now I have added an "external" ACL to these networks,
            and made the <br>
            respective local zones authorized to transfer from this ACL,
            which has the <br>
            gateways of their local networks in there. However, this
            means that anything <br>
            on the main network can transfer from the satellite network,
            and anything from <br>
            the satellite network can transfer from the main network.
            After all, the name <br>
            servers have no way to tell where it's really coming from.
            While everything on <br>
            these networks is owned or otherwise controlled to a
            reasonable extent by me, <br>
            I don't like this. In my book, this is a security issue. I
            think I need a <br>
            better solution for this.<br>
            <br>
            Configuration-wise, this would be a snippet from ns1.lan on
            the main network <br>
            with the relevant bits.<br>
            <br>
            acl external {<br>
                   admin; <br>
                   192.168.10.9; <br>
                   192.168.10.51; <br>
                   192.168.10.52; <br>
            };<br>
            ; ...<br>
            zone "lan" { <br>
                   type master; <br>
                   file "/etc/bind/zones/fwd.lan.db"; <br>
                   allow-transfer { internal; external; }; <br>
            }; <br>
            zone "10.168.192.in-addr.arpa" { <br>
                   type master; <br>
                   file "/etc/bind/zones/rev.lan.db"; <br>
                   allow-transfer { internal; external; }; <br>
            };<br>
            <br>
            The satellite network's name server has a similar
            configuration to this, but <br>
            the other way around.<br>
            <br>
            I have skimmed over these articles so far, but couldn't find
            anything relevant <br>
            in them.<br>
            - <a href="https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkb.isc.org%2Fdocs%2Faa-00726&data=05%7C01%7Cjohn.thurston%40alaska.gov%7C0b4f0d284fe74f09bbf108da9057ba85%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C637981003716610384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FeampwYSFWr%2Bw8CDs%2B3MM2iw5QMZRJYfsLgp7BD17YE%3D&reserved=0" originalsrc="https://kb.isc.org/docs/aa-00726" shash="cht9fG4UIpukpZ2k2x7aaUa9lIQNtxDTVVbQIAcBvwraH5by4+mEZ1HzVJIzspF4+Ld+x6vKFufgINojTn2jatCS75SZgAhvbkmOBo4aiRRG6V/bWDRs/pEKqpfZlgpJpSLUUzWI/J7J6amb88Im5TWrIwsLIyHHoPCdbaHJdkk=" rel="noreferrer" target="_blank" moz-do-not-send="true">https://kb.isc.org/docs/aa-00726</a>
            <br>
            - <a href="https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.zytrax.com%2Fbooks%2Fdns%2Fch7%2Fxfer.html&data=05%7C01%7Cjohn.thurston%40alaska.gov%7C0b4f0d284fe74f09bbf108da9057ba85%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C637981003716922850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2JEmMMWcQU75vK8pbwwqb7hQWWA2%2BYulvfvEzqGPCh4%3D&reserved=0" originalsrc="https://www.zytrax.com/books/dns/ch7/xfer.html" shash="Tka916hshPggm6hAAC/G9b+kVXjfW1FFRQeBmEOozRYM+KvAIrJToLZ3aJGehyOdV2VK+gYbaULwi4zTwFCEATZkG5AekSRXzCvlMN9gT3i34aCq2OFA5KfMNChzv58m9MluWAucq3yk20OY3FnsFcWwirMXOT1WhsELzzC09Ew=" rel="noreferrer" target="_blank" moz-do-not-send="true">
              https://www.zytrax.com/books/dns/ch7/xfer.html</a> <br>
            <br>
            Thank you so much for taking your time to read this, and
            thanks in advance for <br>
            any insights.<br>
            <br>
            -- <br>
            Met vriendelijke groet / Best regards,<br>
            Michael De Roover<br>
            <br>
            <br>
            -- <br>
            Visit <a href="https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users&data=05%7C01%7Cjohn.thurston%40alaska.gov%7C0b4f0d284fe74f09bbf108da9057ba85%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C637981003716922850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=csrSYjv287wE%2FIbg1enHPk%2Bjg%2B1oeTqwWco%2FMafrcrA%3D&reserved=0" originalsrc="https://lists.isc.org/mailman/listinfo/bind-users" shash="PwacdYLdtI7q+PGzqKnFqcmYZUs8twvOef++E27W4LWgc+OXTZalDyYXYniW/E26QMACElzh+VfOQ3syKyA1MzO4dldaQruOKXdiBG5Xw07Y7/B5cmSzA9FOMF247SmfRpRcc2AAWpSnREtG+xZrBHMMm8v7+wfb4HdMK/CCMkk=" rel="noreferrer" target="_blank" moz-do-not-send="true">
              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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.isc.org%2Fcontact%2F&data=05%7C01%7Cjohn.thurston%40alaska.gov%7C0b4f0d284fe74f09bbf108da9057ba85%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C637981003716922850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xrs%2FxtGsaUtcafpNeEd%2Bfw5zElMX0KPOO6kH1tvHzcQ%3D&reserved=0" originalsrc="https://www.isc.org/contact/" shash="M1K8Ae2pxyPRY6TXjlqbp16TmNvDoZIgNnCPR25YVhXDzxCM5JKi752occMSCV09Y04Pfn7S3M4fYshtpywnBEQoOrlXYlpGIyIx3rdKge8ALezZVKCPFoFR9UO3SajBzfAqJMbkDYuymhphADLIUzO9xufwUTyBc2+eN9oE+yo=" rel="noreferrer" target="_blank" moz-do-not-send="true">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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users&data=05%7C01%7Cjohn.thurston%40alaska.gov%7C0b4f0d284fe74f09bbf108da9057ba85%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C637981003716922850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=csrSYjv287wE%2FIbg1enHPk%2Bjg%2B1oeTqwWco%2FMafrcrA%3D&reserved=0" originalsrc="https://lists.isc.org/mailman/listinfo/bind-users" shash="PwacdYLdtI7q+PGzqKnFqcmYZUs8twvOef++E27W4LWgc+OXTZalDyYXYniW/E26QMACElzh+VfOQ3syKyA1MzO4dldaQruOKXdiBG5Xw07Y7/B5cmSzA9FOMF247SmfRpRcc2AAWpSnREtG+xZrBHMMm8v7+wfb4HdMK/CCMkk=" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
          </blockquote>
        </div>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
    </blockquote>
  </body>
</html>