bind9.7.1 Skipping lots of Zone Transfers

[Martin McCormick]

Ah, the wonderful world of high stakes no-return upgrades!

I turned on a new installation of bind9.7.1 after
running it in slave mode for a few days and:

26-Oct-2010 07:30:46.497 zone 78.139.IN-ADDR.ARPA/IN: refresh:
skipping zone transfer as master 139.78.100.1#53 (source 0.0.0.0#0) is unreachable (cached)

These messages are flying in fast and furious at a rate
of about 1500 in 4 hours and the master is otherwise answering
queries and seems to be well. Nothing like going from test mode
to production to find out the truth.

The slave from which I got these errors is also a brand
new installation of bind9.7.1 and is on the same switch as the
master.

If the problem is with the slave configuration, I am not
as concerned as if it is the master so I am trying to figure
this out sooner rather than later as it looks like something
that might effect our site lookups.

Any ideas are appreciated. Most of the error messages in
bind9.7.1 are fairly self-explanitory but this one has me
scratching my head.

Martin McCormick WB5AGZ Stillwater, OK
Systems Engineer
OSU Information Technology Department Telecommunications Services Group

[Alan Clegg]

On 10/26/2010 8:45 AM, Martin McCormick wrote:

> 26-Oct-2010 07:30:46.497 zone 78.139.IN-ADDR.ARPA/IN: refresh:
> skipping zone transfer as master 139.78.100.1#53 (source 0.0.0.0#0) is unreachable (cached)

Are you able to "dig @139.78.100.1 78.139.IN-ADDR.ARPA axfr" when logged
into the slave?

It seems that communications between the slave (which we don't know the
IP address of) and the server at 139.78.100.1 is broken.

AlanC

[Martin McCormick]

Alan Clegg writes:
> Are you able to "dig @139.78.100.1 78.139.IN-ADDR.ARPA axfr" when logged
> into the slave?

No and your diagnosis was spot on.

> It seems that communications between the slave (which we don't know the
> IP address of) and the server at 139.78.100.1 is broken.

Oh, yes! it was definitely broken. The slave is on the
same subnet as the master so any firewalls had to be on one or
the other and it turned out some firewall rules I had been
using for probably 6 to 8 years or so do not work with tcp
transfers. individual lookups worked because they are mostly
udp.

To be truthful, the firewall was low on the trouble-shooting
list because it had worked for so long.

Thanks very much.

Martin McCormick