Разница между 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" ---

Alexey Vissarionov написал(а) к Alexandr Kruglikov в Jul 18 12:40:00 по местному времени:

Доброго времени суток, Alexandr!
13 Jul 2018 18:32:56, ты -> All:

AK> Собственно, $SUBJ. Если можно - по-русски. Гуглом нашёл, что:
AK> Stub zones: only available as a single level beyond one's
AK> "authoritative core", i.e. the stub server must be able to talk
AK> directly to one or more authoritative servers for the zone.
AK> Forward zones: can be daisy-chained an arbitrary number of levels
AK> from the authoritative core (but this is not recommended due to
AK> manageability, performance and reliability concerns).

Ну написано же человеческим по фоновому: stub - спрашиваем у первоисточника, forward - спрашиваем у апстримного ресолвера.

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

Здесь то же самое, но другими словами. Заодно сказано, что первоисточником считаются серверы, указанные в записях NS.

AK> As a general rule, use "type forward" zones only if you have some
AK> connectivity issue you need to work around, e.g. trying to resolve
AK> Internet names from behind a restrictive firewall.

Пример высосан из пальца. Реальное применение для сейчас - в ресолвере на пластмассовом роутере (да и то проще сделать его forward only, чтобы только кешировал). Ну, если локальных зон нет, разумеется.

AK> Use slave zones if you want a full copy of the zone available at all
AK> times (unless it expires of course), thus maximizing fault-tolerance
AK> and client-to-resolver performance, but subject to the replication
AK> overhead, storage space and willingness of the zone owner to allow
AK> zone transfers.

Вторичники - хорошо, ога. Но помимо требования AXFR возникают риски cache poisoning, поэтому лучше фпень (у меня 4 высоконагруженных сервера, и все - первичники).

AK> And use stub zones if you want a more lightweight alternative to
AK> slaving, at the expense of some fault-tolerance and client-to-resolver
AK> performance.

Игого: сервер, где описан stub - это такой недовторичник, который не всю зону тащит по AXFR, а только свои же запросы кеширует, но при этом не проходит всю цепочку от ".", а сразу обращается к первоисточнику.

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

"Учите немецкий - он таки на ваш идиш похож" // (ц)


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Чужие темплейты читают только ламеры с IQ<64
--- /bin/vi