<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">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="http://192.168.10.0/24" rel="noreferrer" target="_blank">192.168.10.0/24</a> subnet, <br>
while the "satellite" network uses the <a href="http://192.168.20.0/24" rel="noreferrer" target="_blank">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="http://10.8.2.0/24" rel="noreferrer" target="_blank">10.8.2.0/24</a> and <a href="http://10.8.3.0/24" rel="noreferrer" target="_blank">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://kb.isc.org/docs/aa-00726" rel="noreferrer" target="_blank">https://kb.isc.org/docs/aa-00726</a> <br>
- <a href="https://www.zytrax.com/books/dns/ch7/xfer.html" rel="noreferrer" target="_blank">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://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>