Zones-unable-update

[Fajar A. Nugraha]

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[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 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 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