zone refresh timeout

[Kevin Darcy]

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