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.thurs...@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 <i...@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@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>
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
