Chaining NOTIFY and slave servers - is it supported?

[Tony Finch]

Petr Bena <petr at bena.rocks> 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:
> https://www.zytrax.com/books/dns/ch7/xfer.html#also-notify

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

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