On Mon, Jan 6, 2020 at 2:03 PM MEjaz <me...@cyberia.net.sa> wrote: > > Thank you for your emai. > > > > I am not cutting any logs, I am capturing only for that particular zone > which I have chooses for the test, as I can't do the test on live zones. > > This time I have noticed "denied" in my slave server logs as below, this is > something very strange sometimes zone transferred perfect after two hours. > > However this time I need to wait and see whether this zone would transfer > after few hours as seen before. > > Jan 6 09:15:33 ns2 named[24436]: client @0x7f1228224460 212.119.92.5#42430 > (kal am.com.sa): zone transfer 'kalam.com.sa/AXFR/IN' denied > Jan 6 09:15:43 ns2 named[24436]: client @0x7f1228272ed0 212.119.93.5#36083 > (kalam.com.sa): zone transfer 'kalam.com.sa/AXFR/IN' denied
Well, fix that. Something is causing the transfer to fail. Is 212.119.92.5 and 212.119.93.5 both allowed to transfer data (e.g. allow-transfer configuration)? > [root@ns2 ~]# dig soa kalam.com.sa @ns1.cyberia.net.sa axfr, "with this I > can fetch all the correct update records" Did you run this on both 212.119.92.5 and 212.119.93.5? > Thanks in advance for your assistance. Do you think that should I take look > from our network side for the MTU size?? It's somewhat harder to check for temporary errors. The easiest way, since you say that this is a "test", is to replicate (i.e. same OS/distro, software versions, configs) your setup on test VMs (or servers, if you have that), on the same network (e.g. VMs with private network 10.x.x.x is fine), and see if it always works there. If yes, then most likely the problem is somewhere in your network (e.g. firewall). If no, then the problem is somewhere in your bind configuration. -- Fajar _______________________________________________ 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
