Slave zone refresh logic

[Bob Harold]

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
> 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.
>
> Regards,
>
> Anand Buddhdev
> RIPE NCC
>
> https://kb.isc.org/article/AA-00726
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150608/e149b71f/attachment.html>