Zone transfer over VPN
John Thurston
john.thurston at alaska.gov
Wed Sep 7 00:14:00 UTC 2022
If you are dealing with two totally private networks, do you even need
the ACL?
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.
I do this by defining a specific key for each secondary server. Then, in
the appropriate view on the hidden primary, I use:
match-clients { none; };
allow-transfer { key nameofkeyhere; };
and on each secondary, I define a 'primaries' and use that in the zone
definitions:
primaries hiddenprimary { 10.20.30.40 key nameofkeyhere; };
zone "foo.bar.com" { type secondary; primaries { hiddenprimary; }; };
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.
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska
On 9/6/2022 2:31 PM, Greg Choules via bind-users wrote:
> Hi Michael.
> 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.
> Do you have logs from all servers? What are they telling you
> specifically about what is the issue?
> 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.
>
> Cheers, Greg
>
> On Tue, 6 Sept 2022 at 23:16, Michael De Roover <isc at nixmagic.com> wrote:
>
> Hello everyone,
>
> I have currently 2 internal networks under my control, both of
> which have BIND
> name servers in them. The "main" network uses the 192.168.10.0/24
> <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>
> subnet,
> while the "satellite" network uses the 192.168.20.0/24
> <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>
> subnet. Following this,
> I will refer to these as main and satellite. You may consider the
> satellite
> network sort of like a road warrior setup, though both are
> fully-fledged
> networks with hosts in them.
>
> The main network has a set of two gateways with IP addresses
> 192.168.10.51,
> and 192.168.10.52. They perform VRRP to each other, with floating IP
> 192.168.10.9. Both of them make a VPN connection to two VPS's
> using WireGuard.
>
> The VPS's have IP ranges 10.8.2.0/24
> <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>
> and 10.8.3.0/24
> <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>
> respectively. Pretty much
> all traffic that's relevant here (AXFR/IXFR on TCP 53) goes
> through the former.
>
> The satellite network does the same thing, it also connects to the
> VPS's but
> does not perform VRRP with another node. The gateway on the
> satellite network
> uses IP address 192.168.20.1.
>
> The name servers on these networks are 192.168.10.4, 192.168.10.5 and
> 192.168.10.6 on the main network, and 192.168.20.3 on the
> satellite network.
>
> This is running on BIND 9.16.25 for Alpine on the main network,
> and BIND
> 9.11.5-P4-5.1+deb10u7-Debian for Debian on the satellite network.
> All of them
> are running in LXC with bridged networking.
>
> Now I would like to get both of these networks to share their
> local zones. So
> in the name servers' configs I would initially declare an ACL for
> this and add
> that to the zone entries, on the main network. This worked fine
> for those,
> being in the same subnet. But once I tried to do the same on the
> satellite
> network, BIND on the main network would see the zone transfer as
> coming from
> 192.168.10.51 or 192.168.10.52 -- instead of coming from
> 192.168.20.3 -- and
> refuse it. The same is true the other way around, where the name
> server on the
> satellite network sees zone transfers from the main network as
> coming from
> 192.168.20.1 instead.
>
> In other words, only the first hop (or the last, depending on how
> you look at
> it) is being considered, with zone transfers seemingly being
> expected to occur
> from within the same subnet. Surely I'm not the only one who dealt
> with this?
> If anything, I consider myself still a newbie. Is it possible to
> get BIND to
> consider the original source of the zone transfer instead?
>
> For now I have added an "external" ACL to these networks, and made
> the
> respective local zones authorized to transfer from this ACL, which
> has the
> gateways of their local networks in there. However, this means
> that anything
> on the main network can transfer from the satellite network, and
> anything from
> the satellite network can transfer from the main network. After
> all, the name
> servers have no way to tell where it's really coming from. While
> everything on
> these networks is owned or otherwise controlled to a reasonable
> extent by me,
> I don't like this. In my book, this is a security issue. I think I
> need a
> better solution for this.
>
> Configuration-wise, this would be a snippet from ns1.lan on the
> main network
> with the relevant bits.
>
> acl external {
> admin;
> 192.168.10.9;
> 192.168.10.51;
> 192.168.10.52;
> };
> ; ...
> zone "lan" {
> type master;
> file "/etc/bind/zones/fwd.lan.db";
> allow-transfer { internal; external; };
> };
> zone "10.168.192.in-addr.arpa" {
> type master;
> file "/etc/bind/zones/rev.lan.db";
> allow-transfer { internal; external; };
> };
>
> The satellite network's name server has a similar configuration to
> this, but
> the other way around.
>
> I have skimmed over these articles so far, but couldn't find
> anything relevant
> in them.
> - https://kb.isc.org/docs/aa-00726
> <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>
>
> - https://www.zytrax.com/books/dns/ch7/xfer.html
> <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>
>
>
> Thank you so much for taking your time to read this, and thanks in
> advance for
> any insights.
>
> --
> Met vriendelijke groet / Best regards,
> Michael De Roover
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users
> <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>
> to unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/
> <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>
> for more information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> <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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220906/87ca6e98/attachment-0001.htm>
More information about the bind-users
mailing list