Unable to transfer IPv4 reverse zone

[Cathy Almond]

On 19/12/2013 23:32, Daniel Lintott wrote:
> I have now tried recreating the zone file on the master, removed and
> re-added the configuration for the zone on both master and slave, yet
> still I am unable to transfer the zone.
> 
> I have also added the following logging to the master server:
> 
> logging {
> 	channel xfer {
> 		file "/var/log/named/xfer.log";
> 		print-category yes;
> 		print-severity yes;
> 		print-time yes;
> 		};
> 	category xfer-out {
> 		xfer;
> 		};
> 	};
> 
> But this fails to log anything, despite transfers taking place. I've
> checked the permissions on the log and it is writeable by the user which
> bind is running under.
> 
> As yet... I'm no closer in working this one out.

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).

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

---

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.

---

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.

Cathy