Chaining NOTIFY and slave servers - is it supported?

Tony Finch dot at
Tue Apr 21 15:22:10 UTC 2020

Petr Bena <petr at> wrote:
> So when someone changes zone on A via nsupdate, NOTIFY and subsequent IXFR
> goes like this: A -> B -> C instead of:
> A -> B
>   -> C

Chaining NOTIFY like A -> B -> C is very common - I would guess most TLDs
do it. In many cases, A is a secure hidden primary, B are zone transfer
servers and NOTIFY relays, and C are the published authoritative servers.

(This kind of setup is pretty standard when C are anycast servers, in
which case B needs explicit also-notify configuration to talk to the
physical node addresses rather than the public anycast service addresses.)

There may be mulitple layers of B too, for example we have our own xfer
servers, and to send our zones to our third-party secondary service
providers, we have to configure their xfer servers not their auth servers.

> What confuses me however, is that I just found this in BIND documentation at:

That's wrong in several ways. It's a third-party guide, it isn't official
documentation, so treat it with caution.

f.anthony.n.finch  <dot at>
Hebrides, Bailey: East or southeast 3 or 4, becoming variable 3 or less at
times. Occasionally rough at first, otherwise moderate. Fair. Good.

More information about the bind-users mailing list