Slave zone refresh logic

Anand Buddhdev anandb at
Mon Jun 8 09:38:38 UTC 2015

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 sequence.

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

More information about the bind-users mailing list