Разница между type static-stub и type forward в zone у bind

Alexandr Kruglikov написал(а) к All в Jul 18 18:32:56 по местному времени:

Привет, All!

Собственно, $SUBJ.
Если можно - по-русски. Гуглом нашёл, что:

Stub zones: only available as a single level beyond one's "authoritative
core", i.e. the stub server must be able to talk directly to one or more
authoritative servers for the zone.
Forward zones: can be daisy-chained an arbitrary number of levels from
the authoritative core (but this is not recommended due to
manageability, performance and reliability concerns).

Stub zones: will use whatever is in the NS records of the zone (or
descendants of the zone, if not otherwise defined) to resolve queries
which are below a zone cut.
Forward zones: will always use the configured forwarders, which must
support recursion, even for names which are known to be deeper in the
delegation hierarchy and whose delegated/authoritative nameservers might
respond more quickly than the forwarders, if asked.

As a general rule, use "type forward" zones only if you have some
connectivity issue you need to work around, e.g. trying to resolve
Internet names from behind a restrictive firewall. Use slave zones if
you want a full copy of the zone available at all times (unless it
expires of course), thus maximizing fault-tolerance and
client-to-resolver performance, but subject to the replication overhead,
storage space and willingness of the zone owner to allow zone transfers.
And use stub zones if you want a more lightweight alternative to
slaving, at the expense of some fault-tolerance and client-to-resolver
performance.

To answer your specific question, the non-intuitive[1] "forwarders { };"
is needed to inhibit forwarding which has presumably been defined at a
higher level (semantically) in your config, either at the
1.10.in-addr.arpa level, or somewhere above that, explicitly, or
so-called "global forwarding" defined in the "options" clause. By
default, named does not forward, so if those were the only 2 zone
definitions in named.conf, and there was nothing about forwarding in
your "options" clause, then you wouldn't need "forwarders { };" in any
of your zone definitions. You only see that directive in "hybrid"
configs, where forwarding is used at one level of the namespace
hierarchy, and then overridden with regular iterative forwarding at a
lower level.

но моего английского не хватило для чёткого понимания...

* Оригинал написан в RU.LINUX
* Скопировано в RU.UNIX

С наилучшими пожеланиями, Alexandr.

--- "GoldED+/LNX 1.1.5-b20170303" ---