Slave zone refresh logic
rharolde at umich.edu
Mon Jun 8 15:43:10 UTC 2015
On Mon, Jun 8, 2015 at 5:38 AM, Anand Buddhdev <anandb at ripe.net> wrote:
> Hi BIND users and developers,
> I'm trying to figure out how BIND 9.10.2 refreshes slave zones. I've
> looked for this information in the ARM, but can't find it.
> Assuming that there are no NOTIFY messages coming in, and it is time to
> refresh a zone, this appears to be the simplest logic:
> 1. Send a query over UDP for zone/IN/SOA to each master listed, in
> 2. If a successful response is received, and the serial number is the
> same, then do nothing.
> 3. If the master doesn't respond, or returns an error of any kind
> (SERVFAIL, REFUSED, FORMERR), then move along to the next master.
> 4. If a successful response is received, and the serial on that master
> is higher, then try to refresh with IXFR or AXFR. If the XFR fails
> (timeout, error), then move along to the next master.
> However, I don't know what BIND actually does. BIND also has an option,
> try-tcp-refresh. I *think* it means that if a SOA query over UDP fails,
> then BIND should just immediately try an XFR over TCP, but I'm not sure
> of its meaning.
> Would someone from ISC be kind enough to explain BIND's refresh logic,
> or even better, write a KB article? It would really help me understand
> how to debug zone transfer failures, and perhaps also tune BIND for more
> resiliency in the face of poorly configured master servers.
> Anand Buddhdev
> RIPE NCC
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users