Thanks for your help. I had some trouble with the log file and after I
got it going I identified the point of failure quickly. The firewall was
misconfigured and applied NAT on internal traffic. However, someone
mentioned that idea. Otherwise I'd probably had banged my head for hours
seeing the wrong slave IP in the log.
Am 26.04.2017 um 10:10 schrieb Steven Carr:
On 26 April 2017 at 08:23, Nico CARTRON <nico...@ncartron.org> wrote:
BIND logs refers to the IP address 172.16.10.16, can you tell us what is this
IP?
It appears that this is this IP address which is trying to transfer the zone,
and as you are restricting zone transfers to the slave IP address
(172.16.11.35), it makes sense that this is refused.
And also explains why it works when you allow the entire /16.
Ah OK, my mistake I thought the log was from the master not the slave.
So 172.16.10.16 is the master, 172.16.11.35 is the slave.
Are there any firewalls or natting taking place between those two IP
addresses that would cause the slave to appear as a different IP? Can
you see anything relating to AXFR in the logs on the master?
If you are on the slave and perform "dig @172.16.10.16
dmz.microsult.de. SOA +tcp" what do you get back?
Also for testing, if you put the ACL back to /16, and perform an AXFR,
you should see in the logs on the master the IP of the slave that has
performed the transfer.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
