zone transfers timeout in bind but work via dig

[Mark Jeftovic]

On Sun, 3 Oct 2004, Christian Smith wrote:

> In article <cjoq8b$28na$1 at sf1.isc.org>,
>  Barry Margolin <barmar at alum.mit.edu> wrote:
>
> > > Because of this, there needs to be an explicit hole punched in the
> > > firewall at the master server to allow outgoing connections in the
> > > 1024-65535 range. And, at the slave end there needs to be a matching
> > > hole to allow in coming connections to those ports (sourced from port
> > > 53).
> >
> > This is totally wrong.  The DNS protocol contains no mechanism like this.
>
> Then explain the difference. DIG works and can transfer the zone using
> AXFR, but actual transfers initiated by a BIND slave fail. I've seen
> this time and again and the problem is always with the firewall rules.
>
> What is different between the way DIG handles the transfer and how BIND
> handles it?
>

In the case of the original situation which prompted my post, it
turned out to "fix itself" after they rebooted the firewall. Since
it started after they moved the private address of the master nameserver
behind the firewall, my guess is a stale arp cache which was cleared
in the reboot.

In more general terms, it usually does come down to the firewall
rules around UDP on port 53. You may be able to do AXFRs or IXFRs
via dig but the running bind won't pull it off unless it can do
the soa query first via UDP (as per the FAQ).

So my guess is what happens is that bind catches the NOTIFY packet,
and then the SOA query fails, but instead of logging "timeout
waiting on SOA response" or something similar, it logs "timeout
waiting for refresh".

-mark