Unable to transfer IPv4 reverse zone

[Daniel Lintott]

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