On 20/12/13 09:16, Cathy Almond wrote: > Noting this in the master zone: >> allow-transfer { >> 192.168.5.2; >> }; > > Check that the slave actually is using that source address for the TCP > transfer (which I grant would be odd to be different, if your other > zones transfer OK). >
The slave is using 192.168.5.2 for the TCP transfer, to be sure I have set the transfer source and confirmed this with a packet trace. > Do you have the same ACL on your other zones that transfer OK? > > And depending on the 'big' configuration - this might also be relevant: > https://kb.isc.org/article/AA-00904/47/Why-is-my-slave-server-trying-sometimes-to-use-a-different-source-IP-address-for-zone-transfers.html > All of the zones have identical ACL's as above. > --- > > If still unresolved, I think I'd be at the point of doing a network > packet trace on this one to find out which end is dropping it. The > earlier logging messages suggest that the TCP connection for the > transfer did establish (or start to establish - it may not yet have been > 'connected' all the way to the named server). > > Trace at both ends simultaneously, so that you get both sides of the > 'story'. And also trace a good transfer between master and slave for > comparison purposes. > Looking at a packet trace, I can see the TCP session establish, the AXFR request is sent to the master which responds with 'SERVFAIL' Pkt 160: Standard query 0x3a9c AXFR 5.168.192.in-addr.arpa Pkt 173: Standard query response 0x3a9c Server failure As a thought, I have tried running the AXFR on the master server, which also fails.... so it would seem the problem lies on the master server. [root@server1 ~]# dig 5.168.192.in-addr.arpa @127.0.0.1 AXFR ; <<>> DiG 9.9.4-P1 <<>> 5.168.192.in-addr.arpa @127.0.0.1 AXFR ;; global options: +cmd ; Transfer failed. > --- > > It shouldn't be relevant to the problem in-hand, but are you missing > this record from your reverse zone (I didn't see it in the ANY query > result): > > 2.5.168.192.in-addr.arpa. IN PTR server2.internal.serverb.co.uk. > The record does appear to to be in the zone. Regards Daniel _______________________________________________ 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