FW: Named service not sending transfers
kcd at chrysler.com
Fri Jun 13 00:37:47 UTC 2008
Lopez, Denise wrote:
> Content-Type: text/plain;
> 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
> Hi all,
> 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.
> Is there something else I need to set to get the transfer working?
> 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.
More information about the bind-users