zone refresh timeout
Kevin Darcy
kcd at daimlerchrysler.com
Tue Mar 22 00:36:28 UTC 2005
Stephane wrote:
>Hello,
>
>I currently have 2 dns servers running, slave and master, holding the
>same domains zones, which have 2 NS defined as this 2 servers.
>
>I now want to set up a third nameserver. I configured it and it is
>running, answering to dig queries.
>It holds the same zones as my slave nameserver.
>But it can't refresh the zones it holds, as shown in the logs:
>general: info: zone exple.com/IN: refresh: failure trying master
>81.28.111.11#53: timed out
>
>If i define this new nameserver as a NS in a domain zone, the zone is
>well refreshed.
>So my question is, am I forced to declare this new nameserver as a NS
>in each zone on the primary in order to have this zone refreshed on
>the new dns server?
>
No, that shouldn't be necessary. I have dozens of "stealth slave"
servers and they work fine.
My guesses are
a) that you misdiagnosed the problem. Maybe it's just a coincidence that
the timeouts went away at about the same time you added the slave into
the NS records, or
b) you might have some of strange firewall in the way that allows zone
transfers only within a certain time interval after communication is
initiated from the master's side. When a slave is listed in the NS
records for a zone, the master will, by default, send a NOTIFY packet to
that slave whenever the zone changes. Maybe that NOTIFY is "opening the
door" in your firewall temporarily so that the zone transfers succeed.
You can test guess (a) by trying things both ways (with the slave in the
NS records and without it).
You can test guess (b) by taking out the NS record but adding the slave
to the "also-notify" list for the zone. That should have the same NOTIFY
effect.
>can't i just get a refreshed copy of the zone when it's ttl has
>arrived?
>
Not sure what you mean by that. Replication between masters and slaves
is not controlled by TTL. It's controlled by the REFRESH setting in the
SOA record of the zone. But, the error message you quote above denotes
that the slave server is *trying* to transfer the zone but is timing out
trying to do so. So it's not that the zone transfers aren't frequent
enough; rather, they don't appear to be succeeding at all (except
perhaps when the slave is published with an NS record, as discussed above).
- Kevin
More information about the bind-users
mailing list