FW: Named service not sending transfers

Kevin Darcy kcd at chrysler.com
Fri Jun 13 00:37:47 UTC 2008

Lopez, Denise wrote:
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> From: Lopez, Denise=20
> Sent: Friday, June 06, 2008 12:50 PM
> To: 'bind-users-bounce at isc.org'
> Subject: Named service not sending transfers
> =20
> Hi all,
> =20
> I just recently updated our BIND server from 9.2.1 to 9.3.4.  I have 5
> IP addresses in an acl called xfer and I allow xfer in the options
> allow-transfer.  When I restart the named service, there is nothing in
> the logs that show the transfer of an updated zone and the 4 slave
> servers do not receive the transfer either.
> =20
> Is there something else I need to set to get the transfer working?
> =20
> =20
> Thanks in advance for any input.
Well, let's break down the problem a bit.

Do the slaves *eventually* get the transfer, i.e. within the REFRESH 
interval set on the zone?

If not, then you have a problem with basic master->slave replication. 
There could be multiple causes, e.g. a misconfigured firewall, a typo in 
your allow-transfer acl, multi-homed slave is attempting to zone 
transfer from an address not listed in the acl, etc. In order to 
troubleshoot *this* type of problem, you might need to hop on one of the 
slaves and reproduce the problem by manually trying to transfer the 
zone(s), using "dig" or your favorite DNS troubleshooting tool.

If the slaves *eventually* get the transfer, then this is a _different_ 
type of problem, essentially a timing problem. The NOTIFY extension to 
the DNS protocol should ensure that changes to a master zone propagate 
quickly to "known" slaves. By "known" I mean, either a slave which is 
*published* in the NS records of the zone, or which is "manually" 
configured via "also-notify" in your named.conf. A slave will, by 
default, reject a NOTIFY that comes from an address not listed in the 
"masters" clause of the zone, so, again, if the master is multi-homed, 
this is one possible cause of the problem (which you can fix by 
specifying "notify-source" on the master, or specifying "allow-notify" 
on the slave).

Regardless of which type of problem you're dealing with here -- basic 
replication failure, or NOTIFY/timing issue -- one of the first places 
you should look is in the logs, both on the master and on the slaves. 
The important stuff should be visible even with default logging 
parameters, but if you want to dive deeper, you might need to turn up 
the "notify" and/or "xfer-in"/"xfer-out" categories in your logging 
configuration in order to get more detailed info.

    Can I force a transfer of a zone?


Yes, if you have rndc configured for the slave(s), you can use the 
"refresh" or "retransfer" command.

    Doesn't that happen automatically when the service is restarted?

Restarted, on the master or on the slave(s)? Hopefully you understand 
that DNS zone transfers are a "pull", not a "push". So you'd need to 
restart the service on a *slave* (or use the refresh or retransfer rndc 
commands, as mentioned above) in order to "force" a transfer of the zone.

NOTIFY enhances the classic "pull" model of DNS replication by having 
the master reach out and "tickle" the slaves, whenever a change to the 
zone occurs, but ultimately the responsibility for initiating zone 
transfers rests with the slaves, not the master. Bottom line: if you 
want changes to propagate quickly and automatically, within the DNS 
protocol itself, you need to get your NOTIFYs working properly.

                     - Kevin

More information about the bind-users mailing list