Fajar A. Nugraha
fajar at fajar.net
Mon Jan 6 07:58:59 UTC 2020
On Mon, Jan 6, 2020 at 2:03 PM MEjaz <mejaz at 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: client @0x7f1228224460 22.214.171.124#42430 (kal am.com.sa): zone transfer 'kalam.com.sa/AXFR/IN' denied
> Jan 6 09:15:43 ns2 named: client @0x7f1228272ed0 126.96.36.199#36083 (kalam.com.sa): zone transfer 'kalam.com.sa/AXFR/IN' denied
Well, fix that.
Something is causing the transfer to fail. Is 188.8.131.52 and
184.108.40.206 both allowed to transfer data (e.g. allow-transfer
> [root at 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 220.127.116.11 and 18.104.22.168?
> 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
If no, then the problem is somewhere in your bind configuration.
More information about the bind-users